FolderItem.Delete Occasionally Fails

General
#1

I’m finding that rarely, maybe 1 in 200, FolderItem.Delete will fail and the .ErrorCode will be 0.

This is happening on both Mac and Windows using 2017r1 and before.

Anyone else notice this?

I’m saving to a temp file, using ExchangeFilesMBS to exchange that with the actual file, then creating brand new FolderItem reference to the temp file and deleting it.

In the end, I’ve resorted to scanning for the leftover temp files on exit and deleting them.

#2

I have noticed that. My solution (as I recall) was to call it in a loop that checks to see if it still exists, but you have to create a new FolderItem between the calls to get it to “refresh”. Something like…

for index as integer = 1 to 100 // Prevent endless loop
  if not f.Exists then
    exit for index
  end if
  f.Delete
  f = new FolderItem( f.NativePath )
next index

Or you can start a shell to remove the file.

#3

I think I’ll try that!

I imagine also that using Xojo.Core.Timer.CallLater to delay deleting it might do the trick.

#4

Hi,

And in your loop Kem, if f is an alias and the first delete fail, you try to delete the file pointed by the alias in the next loop, or am I wrong?

What’s the difference between f = new FolderItem( f.NativePath ) and f = GetFolderItem(f.NativePath) ? Why New ?

How can I do something like f = new TrueFolderItem( f.NativePath ) (equivalent to f = GetTrueFolderItem(f.NativePath))

#5

I haven’t tried, but I think you’re right. f = GetTrueFolderItem to recreate the FolderItem looks like the better option.

#6

In this thread , I explain I have to loop a first time on 2 items and then loop on all items of a folder to get all of them (because sometimes it doesn’t see some of them).

An equivalent thing in your case could be :

Fin_iNbre = Min(f.Parent.Count, 2) ' Maybe test before if f.parent not Nil but we won't erase a volume ?! For iNbre = 1 to Fin_iNbre ' I do not need to loop in all items, just 1 or 2 (I loop 2) TampItem = f.parent.TrueItem(iNbre) ' I don't do anything, just call a item in my ParentFolder Next iNbre
and then delete f

f.Delete
#7

At least on macOS you can find that files are sometimes held “busy” and can’t be deleted.
We’ve seen this in the IDE as well hence why you sometimes get “Project failed to compile”
trying

lsof <path to file>

in terminal often points to a system level process for files that fail to be deleted

Windows I’ve rarely seen this issue

#8
#9

I’ve just come across a similar problem when trying to overwrite PDF files, and Norman’s suggestion of using lsof <path to file> was really helpful: it seems that if you just have the file selected in Finder, it’s locked by both Finder and QuickLook but FolderItem.Delete fails with no error code. Deselect the file in Finder and all is fine.

I’ve tried replicating this in a sample project but that returns error code 104, which is what you’d expect if the file was in use by something else.

It seems a bit harsh for there to be a lock on the file when it’s just selected in Finder and displaying a QuickLook preview. Using Preview.app, I can happily overwrite an existing PDF that’s selected in Finder, but Xojo can’t.

#10

This could be a result of Preview and Xojo using different OS API’s for file access

#11