"Move to Trash" works differently when used on a computer with iCloud Backup.

I got confirmation from one of my testers today that a change in App Wrapper solves the problem whereby my application’s files were being created in the Trash.

Which strengthens my theory that the macOS function “Move to Trash”, which is normally Synchronous, becomes Asynchronous with iCloud Backup enabled. App Wrapper uses “Move to Trash” just on the off-chance that the user may need those files.

  1. Take a copy of the NativePath of the folderitem (in theory any path format should work).
  2. Rename the existing item.
  3. Call “Move to Trash” on the renamed item.
  4. Recreate the folderitem from the saved path.
  5. Continue normally.

btw: I am using [NSFileManager trashItemAtURL:resultingItemURL:error:]

I can find no evidence of behavior changes in the documentation.

Huh, that’s curious and I’d call it a misbehavior (bug), because that function is clearly meant to be synchronous.

There’s also the older (now deprecated) API for trashing multiple items that works asynchronously, and I’d expect that to behave correctly, ie. you’d get the callback only after the file was actually moved.

Either way, thanks for sharing. In fact, I’d bring it up on StackOverflow, asking for comments on this strange behavior, so that it also becomes more widely known that way.

Where is located the Trash when the original item is in the Cloud ?
In your local computer, Move to Trash send the item (to de lete) to its own disk Trash (boot disk Trash if the item resides on that hard disk, in the external hard disk if the item resides there, etc.)