Temporary FolderItems - Recovered Items in Trash

  1. ‹ Older
  2. 4 weeks ago

    Michael D

    Jul 24 Pre-Release Testers, Xojo Pro

    @Greg OLone There is. Instead of just creating, using temporary folderitems and letting them go out of scope, create a new class which contains a temporary folderitem which will automatically delete the file(s) for you when the class' destructor fires.

    Greg, the problem seems to come from Mutex objects, which do not provide any options for where the temp file is located.

  3. Emile S

    Jul 24 Europe (France, Strasbourg)

    Recovered Items ?
    I have data there each time I fire Xojo and watch the Language Reference.

    Howecer, isn’t SpecialFolder.Temporary holds these files i a folder (called Recovered Items) ?

    If so, I would add code in Cancel Quit (or Quit) Event that scan that folder and if it find a folder called Recovered Items, open it, clears it and delete it (at last).

    Isn’t it possible to do that ?

  4. Michael D

    Jul 24 Pre-Release Testers, Xojo Pro

    @Emile S Recovered Items ?
    If so, I would add code in Cancel Quit (or Quit) Event that scan that folder and if it find a folder called Recovered Items, open it, clears it and delete it (at last).

    Isn’t it possible to do that ?

    I believe that leftover items in the Temp folder are moved to the Trash/Recovered Items folder upon reboot, so that your Xojo app would never have a chance to do that, unless your Xojo app runs automatically upon login (which mine does not).

  5. Emile S

    Jul 24 Europe (France, Strasbourg)
    Edited 4 weeks ago by Emile S

    @Michael:

    The folder may be stored elsewhere in the hidden OS files.

    I’ve made a search including System Files + visibles but I do not found one, before reboot.

    Time to sleep now.

    Edit: finish a sentence and add the last one.

  6. Greg O

    Jul 25 Xojo Inc Somewhere near Raleigh, NC

    @Michael D Greg, the problem seems to come from Mutex objects, which do not provide any options for where the temp file is located.

    I'm curious why the mutex file isn't being destroyed when you call Mutex.Leave as your app quits. We use a mutex for Feedback and it doesn't suffer from this problem.

  7. Tanner L

    is not verified Jul 25 Pre-Release Testers, Xojo Pro Toronto, Canada

    @Greg OLone I'm curious why the mutex file isn't being destroyed when you call Mutex.Leave as your app quits. We use a mutex for Feedback and it doesn't suffer from this problem.

    I don't know if it's a mutex causing this, but Feedback is leaving a temporary file behind. I just opened Feedback 2017r1.2, then closed it and logged out. Upon logging back in my .Trash directory contained a 0 byte file named "Xojo Feedback" in a dir named "Recovered files".

    Here's info on that file:
    $ ls -l@ -rw-r--r--@ 1 user staff 0 Jul 25 06:55 Xojo Feedback com.apple.FinderInfo 32

    This is on OSX 10.11.6.

  8. Kem T

    Jul 25 Pre-Release Testers, Xojo Pro New York

    I just did a quick test. Entering a Mutex does indeed create a file in Temporary, and Leaving it deletes it. Quitting without explicitly calling Leave deletes it too, but perhaps if it's located somewhere where its Destructor doesn't necessarily fire, it won't.

    If it's the Mutex at all, perhaps explicitly call Leave in the App Destructor? Or do what I do, create a wrapper class that holds the Mutex (or a Semaphore or CriticalSection) that calls Leave in it's Destructor. I use it like this:

    dim m as new Mutex( "MyApp" )
    dim holder as CSHolder = CSHolder.TryEnter( m )
    if holder is nil then
      // Couldn't get it
    else
      // Some code
      holder.Leave // Not strictly necessary as its Destructor will Leave it
    end if

    If your code exits early from, say, an exception or early return, the Mutex should still be unset.

  9. Kem T

    Jul 25 Pre-Release Testers, Xojo Pro New York

    BTW, telling your customer to get a life is another good option...

  10. Greg O

    Jul 25 Xojo Inc Somewhere near Raleigh, NC

    FWIW, I just did an experiment and the Mutex temp file is currently being put in SpecialFolder.Temporary on macOS. You could just check and make sure it's being properly deleted.

  11. Michael D

    Jul 25 Pre-Release Testers, Xojo Pro
    Edited 4 weeks ago by Michael D

    @Tanner L

    @Greg OLone I'm curious why the mutex file isn't being destroyed when you call Mutex.Leave as your app quits. We use a mutex for Feedback and it doesn't suffer from this problem.

    I don't know if it's a mutex causing this, but Feedback is leaving a temporary file behind. I just opened Feedback 2017r1.2, then closed it and logged out. Upon logging back in my .Trash directory contained a 0 byte file named "Xojo Feedback" in a dir named "Recovered files".

    Right, that's the same behavior I posted in my 2nd message in this thread (but I see it under 10.12.5).

  12. Beatrix W

    Jul 25 Pre-Release Testers Europe (Germany)

    Stupid question: isn't it the job of the OS to clean up temporary folderitems? Otherwise, I just create and delete those type of files myself. I don't want to mismanage an "rm something" and upset some customers. Wasn't it Adobe which deleted the first folder of the harddisk at some time?

  13. Michael D

    Jul 25 Pre-Release Testers, Xojo Pro

    @Kem T BTW, telling your customer to get a life is another good option...

    For every bug that is reported by customers, I'm pretty sure 99 other ones are not, so I try to be appreciative that they took the time to report it at all. I agree that this particular one seems like a very small issue to me, but I really want to find out what's happening so that I can tell them whether it can or can't be fixed.

  14. Tanner L

    is not verified Jul 25 Pre-Release Testers, Xojo Pro Toronto, Canada

    @Michael D Right, that's the same behavior I posted in my 2nd message in this thread (but I see it under 10.12.5).

    Similar, but Greg mentioned Feedback app as being unaffected by this, and my message specifically counters that claim.

  15. Greg O

    Jul 25 Xojo Inc Somewhere near Raleigh, NC

    @Tanner L I don't know if it's a mutex causing this, but Feedback is leaving a temporary file behind. I just opened Feedback 2017r1.2, then closed it and logged out. Upon logging back in my .Trash directory contained a 0 byte file named "Xojo Feedback" in a dir named "Recovered files".

    Here's info on that file:
    $ ls -l@ -rw-r--r--@ 1 user staff 0 Jul 25 06:55 Xojo Feedback com.apple.FinderInfo 32

    This is on OSX 10.11.6.

    I did check this today and was able to get it to leave the file there. I've added code to delete the file if it still exists after we call Leave.

  16. Sam R

    Jul 25 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @Greg OLone I did check this today and was able to get it to leave the file there. I've added code to delete the file if it still exists after we call Leave.

    I have noticed this recently that folderitem.delete is not 100% reliable, I suppose I should check for errors when it fails. I resorted to moving the files to the trash that I couldn't delete, but in this case it wouldn't solve the OPs problem of customer complaints over temp files in the trash.

  17. Norman P

    Jul 25 Xojo Inc

    when you do find that it doesn't get deleted its often a system level process that is holding it busy
    I've encountered various system ones like mdiutil

    lsof will tell you which utility is doing this
    lsof <file>

    I know some people have resorted to issuing a "rm" in a shell BUT - big Unix warning here - RM only removes the file when the LAST busy reference to it is gone
    And IF that never occurs you have a file that is gone from the file system as far as you are concerned but that CAN suck up all your disk space if whatever has it open & busy just continues to write to that file

    Note the man page for RM says
    The rm utility attempts to remove the non-directory type files specified on the command line. If the
    permissions of the file do not permit writing, and the standard input device is a terminal, the user is
    prompted (on the standard error output) for confirmation.

    https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/rm.1.html

    RM is not necessarily a "fix"

  18. Sam R

    Jul 25 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @Norman P I've encountered various system ones like mdiutil

    I noticed this yesterday, while trying to write video out, the console gets full of lots of messages from various services starting with 'md' and 'ql' about how they can't understand the video, while I'm bleeding writing it to disk! At least wait until I'm finished you morons.

  19. Beatrix W

    Jul 25 Pre-Release Testers Europe (Germany)

    @Greg: did you fix the mutex in general or only the Feedback problem?

  20. Greg O

    Jul 26 Xojo Inc Somewhere near Raleigh, NC

    @Beatrix W @Greg: did you fix the mutex in general or only the Feedback problem?

    On Feedback.

    My instinct says it has something to do with the way it was coded though, as Feedback is designed not only to prevent multiple versions from launching, but to also transfer any new command-line options to the running instance.

    Essentially, in the Open event we were doing this:

    if not mtx.TryEnter then
      SendCommandLine
      TellUser
      Quit
    End If

    And then the Close event looked like this:

    if mtx <> Nil then
      Try
        Mtx.Leave()
      Catch ex as IllegalLockingException
      End Try
    End If

    It seems that the problem is arising from the call to Mutex.Leave when TryEnter returned False. I simply added mtx = Nil just after the TryEnter call, thus causing the Leave block to not be called in that instance. Then after the TryCatch we also attempt to delete the Mutex file.

    I have a bug report in progress and it'll be reported today, along with the workaround.

  21. 3 weeks ago

    Michael D

    Aug 4 Pre-Release Testers, Xojo Pro

    @Greg OLone I have a bug report in progress and it'll be reported today, along with the workaround.

    Hi Greg - any updates on this?

or Sign Up to reply!