Temporary FolderItems - Recovered Items in Trash

Targets macOS
21

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

22

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.

23

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”.
[/quote]

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

24

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?

25

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.

26

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

27

[quote=342064:@Tanner Lee]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.[/quote]
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.

28

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.

29

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

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”

30

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.

31

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

32

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.

33

Hi Greg - any updates on this?

34

Bump - Greg, is there a bug report that we can see?

35

@Greg O’Lone : hi Greg, I’ve got a customer complaining about this again. Any news?

36

Update: in my case, I determined that I was storing an array() of Mutex as a global property in a module. I subclassed the Mutex and put a breakpoint in the Destructor, and determined it was never firing. It appears that arrays in modules are not destroyed before app.close is called. Huh. I never knew that.

In any case, I added an explicit call in App.close to redim the array, and (in a belts and suspenders kind of way) also added the following code to my Mutex subclass:

Sub Constructor(name as string)
  me.mName = name ' remember our name for later
  // Calling the overridden superclass constructor.
  Super.Constructor(name)
End Sub

Sub Destructor()
  #if TargetMacOS
    ' possible workaround for https://forum.xojo.com/41722-temporary-folderitems-recovered-items-in-trash
    dim f as FolderItem = SpecialFolder.Temporary
    if f <> nil then
      f = f.child(mName)
      if f <> nil and f.exists then
        system.debuglog CurrentMethodName + " deleting " + f.name
        f.delete
      end if
    end if
  #endif
  End Sub

Does this fix the problem? Not clear yet.

37

I need to do more checking in my case.

  1. I only use one semaphore in what I call Setup window. It’s not a window that a user would open in every day use of my app. I’ve asked the user about this.

  2. Should I see the temp file when doing the semaphore? I’ve tried and can’t see it with Find Any File.

38

[quote=350264:@Beatrix Willius]I need to do more checking in my case.

  1. I only use one semaphore in what I call Setup window. It’s not a window that a user would open in every day use of my app. I’ve asked the user about this.

  2. Should I see the temp file when doing the semaphore? I’ve tried and can’t see it with Find Any File.[/quote]

Semaphore or Mutex? I’m seeing the issue with Mutex objects.

39

Don’t have a Mutex only a Semaphore.

40

Sorry yes. What I ended up doing is what I described above.

mtx = new mutex(“appname”) If not mtx.tryenter then Mtx = Nil Quit End if

Then in app.close

[code]if mtx <> Nil then
Mtx.leave
End if

Dim f as folderitem = specialfolder.Temporary.child(“appname”)
F.delete[/code]

That seems to have fixed the Feedback issue.