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.
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
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
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
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.