Regarding NSFileManager and "Put Back"

[nathanblair]

I wonder if, rather than the FSFileManager:trashItemAtURL API, this would be an approach that would feel more native to macOS?

Unfortunately I'm not an expert at the Apple Development ecosystem. Nor Objective-C or Swift. Or...really rust for that matter 😅 so I'm not sure if this suggestion is actually entirely unrelated.

As I understand it, NSFileProviderExtension isn't applicable to macOS but this Discussion makes me feel like that's exactly what Finder is doing under the hood (or any macOS app that allows native Trashing behavior).

Is getFileProviderServicesForItemAtURL an option for getting an appropriate FileProvider and then seeing if trashItemWithIdentifier could be called on it?

From here:

When the user moves an item to the trash, the system sets its parentItemIdentifier to NSFileProviderTrashContainerItemIdentifier. Your extension must enumerate all trashed items on request.

It seems like performing that set would be a prerequisite for natively allowing what is desired out of #109?

I hate the thought of needing to write an entire NSFileProviderExtension, or subclass it or whichever, just to get "native" Trash'ing on macOS - but is possible that is what Apple would expect?

I suspect the complexity of what should be as simple as moving a file into the user's Trash folder on macOS arises from the integrated iCloud/shared remote storage capability baked into the file system now? And that would be why there is this NSFileProviderExtension abstraction over top of the Trash'ing capabilities of files?

[Byron]

Thanks for bringing this up!

I also am not knowledgable in this area (like in "no clue"), but I like the sound of have a less hacky version of putting things into the trash on MacOS as well. Maybe one day someone will come along who can implement it on MacOS.