Implement deletion using trashItemAtURL

[ArturKovacs]

Currently on the main branch we are deleting by using an AppleScript telling Finder to delete items. However there are native Objective-C APIs that allow doing this for example trashItemAtURL.

[ArturKovacs]

Following up on #14 (comment) ...

I implemented this on the v2-dev branch and to me there was a Put Back option, and when I click it, it puts back the file to where it was deleted from. The following is after executing cargo run --example delete_method on the v2-dev branch.

@JakeChampion I'm wondering what I did differently; could you test this? If the Put Back option turns out to work in all cases when using the trashItemAtURL, then I think that should be the default deletion method.

[JakeChampion]

@ArturKovacs It looks to not have "Put Back" option for me:

I used the v2-dev branch and ran cargo run --release --example delete_method

My computer stup is:

• Mac OS X 10.15.7
• cargo 1.48.0 (65cbdd2dc 2020-10-14)

[ArturKovacs]

The thing about this is that using a trashing method that doesn't allow to "Put Back", just seems to defeat the whole purpose of using the trash instead of deleting the file permanently.

But we are not the only ones who suffer from this behavior; this seems to be a bug in macOS. See: sindresorhus/macos-trash#4

It's actually somewhat funny how bad the trashing APIs are on macOS. It's not that they are badly designed, because they are pretty clean, to be fair. However it's not only a lot more limited than what you can do on Windows and Linux but even what's available is broken. And has been broken for 6 years now.

[ArturKovacs]

I'm currently considering simply not supporting the NSFileManager/trashItemAtURL at all. Again it is pretty much pointless to put things into the Trash if you can't ever get them back.

What are your thoughts on this @JakeChampion and @disconsented?

[JakeChampion]

I'm with you on that decision, it is impressive how this macOS bug has been around 6 years and not fixed

[disconsented]

We decided to implement it to avoid that one single scary pop-up, however, I don't think the loss of put back makes sense in this context.

It'd be a nice option, but I don't think many folks would mind if it wasn't implemented.

[ArturKovacs]

It'd be a nice option

How so? Let me clarify my perspective, so that you can point out what I'm missing:

I believe that the purpose of the Trash is to be able to change one's mind after deleting something and restore/put back items to their original location. However if restoring is not possible then putting items into the Trash is the same as permanently deleting them.

Using the AppleScript+Finder method produces a dialogue asking for additional permissions. Using the NSFileManager method prevents "Put Back". Therefore if the additional permission dialogue needs to be avoided, then the program should either not move items to the Trash at all (because that cheats the user, as they won't be able to "Put Back"), or the program should remove the file permanently with for example std::fs::remove_file or std::fs::remove_dir_all.

Supporting the NSFileManager method seems more harmful than useful, considering that NSFileManager makes it seem that files can be restored, but in reality they are banished forever.

[JakeChampion]

Supporting the NSFileManager method seems more harmful than useful, considering that NSFileManager makes it seem that files can be restored, but in reality they are banished forever.

They can be restored by the user moving the files out of the trash and placing them somewhere on their machine. Which is different to permanently deleting the files but not as user friendly as having a "put back" option which restores the file to it's original location in the storage system.

[ArturKovacs]

Oh, I did not realize that. I'm a noob at using macOS. Alright, in that case I'll leave this option available, but keep the Finder method as the default. Thanks a lot for the input from both of you, it was very helpful!

[disconsented]

Yep, the only other thing that is different is the lack of the put back option in finder.

I'd looked into this, and supposedly we'd need to manipulate .DS_Store in order to have the prompt but that's quite a lot of effort.

[theodore-s-beers]

I think that macOS users will be rather accustomed to permission request dialogs by this point. It's probably better to live with that, than to sacrifice the "Put Back" option (though I agree with the earlier comment that avoiding permanent deletion is a significant benefit in itself). Just my two cents as a happy user of this library.

[ArturKovacs]

Thanks for your thoughts @theodore-s-beers, it seems that keeping the Finder method as default was a good choice. On that note, version 2 is released now.

[ArturKovacs]

Closing this as it was implemented in #11