folderitem.createFolder and folderitem.remove - timing issues?

I’m having some problems with folderitem.createFolder and folderitem.remove (i.e. the new API).

The problem is not consistent - so difficult to track down. I’m tracking for ioExceptions using Try-Catch for both but get no exceptions reported.

Prior to moving a file to the new folder I test to see if that folder.writable - but often it will show as not writeable.

Similarly, for folder deletion, I first remove all the files from the folder then test that the folder.count is 0 - but often the folder count continues to show > 0 even after its content (files and folders) have been removed.

So my thought is that this might be a timing issue - e.g it is taking some time to create the folder or remove its contents. I’ve tried adding short delays but not seeing much change.

Did you delete the invisibles files too ?
(All platforms)

[quote=487672:@Emile Schwarz]Did you delete the invisibles files too ?
(All platforms)[/quote]
A good question - but there should be no invisible files in these folders.
Just - checked - no invisible files present.

Why are-you writing that ?

Excepted on Linux (I do not know), invisible files may be everywhere (macOS and Windows).

That is the OS who add invisibles files… under conditions and OS versions.

Well, the folders are purely folders created by the app, containing files created by the app. Further, I checked some examples and there were no hidden files in the folders.

They usually are created when the folder is opened.

They can be deleted if your code loop thru the folder contents using an index and no one open that folder at delete time.

So, probably something else.

What is/are the name of the items when the count is > 0 ?

Some example code. This is to delete chains of folders that are empty once deleting the last file at the bottom of the folder chain. It calls itself to try to remove the parent folder, but fails on second pass through as the count is 1 not 0 (even though the folder is now empty).

[code]Private Sub file_delete_FolderChain(f as FolderItem)

//add in short delay to allow finder to remove folder/file before being asked for a count
DelayMBS(0.1)

If f = Nil Then Return

//iterative to remove folders

If f.Count = 0 Then //folder is empty
//first get the parent
if f.parent = nil then return
Dim p As FolderItem = New folderitem(f.parent)

//need to exit here if this is the path of the source file - 
If p = Nil Or p<> Nil And  cData_source.myDisk_source <> Nil And p.NativePath = cData_source.myDisk_source.NativePath Then
  //don't try to delete above this
  Return
End If

//then delete self
If f <> Nil Then //double check, even though already checked
  Try
    f.remove
  Catch err As IOException
    
    Select Case err.ErrorNumber
    Case 0 
      //ignore
    Else
      Dim m As String = "Folder not deleted."
      Dim type As logEvent.eType = logEvent.eType.Warning
      Dim le As New LogEvent(New pvFile(f), m, type)
      Return
      
    End Select
    
  End Try
  //then move to parent and start again
  iFoldersDeleted = iFoldersDeleted + 1
  
  If p <> Nil And p.exists Then file_delete_FolderChain(p)  //move up the chain
  
End If 

End If

Exception err
If Not app.errH.handleException(err, currentMethodName) Then
Raise err
End If
End Sub
[/code]

Can you make a test with all folders (inside the master folder and included to be deleted) closed before removing anything ?

As I wrote earlier, macOS (and Windows) wrote (invisible) files at folder close time.

If the above change nothing, can you check the name of the not deleted items ?

Emile - thank you - you seem to be correct - .DS_store is left there for a while. I suppose safe to delete by name…

So now down to why creating a new folder shows up as .isWriteable = false?

Depends on where it was created…

It may be time to make a break… to drink something ? :wink:

In your timezone yes - still a bit early for here - people might start to talk.

It’s Beer:30 somewhere :slight_smile:

If you sleep your app for, say, 2 seconds between creating the folder and checking its writability, if the result still wrong?

I have tried that - but only 0.1 secs - but didn’t seem to make much difference - however I’ve not been seeing the crash recently so will have to keep monitoring.

I do notice that it occurs more often in runtime than in debug - which I assume is because the app is running faster relative to Finder in the former case.

For some timing issues, I would not consider 0.1 second to be safe for diagnosing.
If you suspect timing issues, start by waiting “too long”, like 5 seconds, between the command and the check. If it works as expected, repeat with only 2 seconds; repeat by reducing until the result is consistent with the delay. If you get a delay where a wrong result is almost always true (perhaps trying several times with each delay), you may start assuming it’s a timing issue.
This process aims at differentiating timing issues with other “random” issues.

The Finder has not so much to deal with this; it’s just the parent process of your app, if you launched it from within the Finder (if you launch it using, say, the Dock, the Finder has nothing to do with your app (unless you target it with AppleEvents/AppleScript). In fact, you can even quit the Finder (e.g. with an AppleScript script) and your app would certainly run the same.
That being said, it’s true there are differences between stand alone vs debugged apps; the communication between the app and the IDE (e.g. for breakpoints or break statements; also exceptions handling) is an obvious difference.