Direct trashing on MacOS?

[eugenesvk]

What do you think about adding direct support to deleting/restoring files on a Mac without using the existing deficient APIs?

On a Mac your library uses (as far as I understand) two methods:

• (main) AppleScript
• obj-c APIs with FileManager

The AppleScript has the documented downside (slow, beeps, asks for permissions, requires Finder (which if you use an alternative file manager adds an extra startup delay) etc), but enables put back

The FileManager has to main issues:

• an OS bug that there is no put back
• its sudo version moves to the inaccessible root trash by default, maybe there is a fix, but the standalone mac tool using this API doesn't know how to fix that (issue), though that should not be an issue for a library since the app using that would request permissions without having to run as root?

but it has not other issues like AS. This could be solved by manually editing .DS_Store, but it was rejected due to:

• undocumented/potentially unstable format
  • this could be guarded against that by checking OS version at runtime and bailing out if it's higher than the latest tested X where it's confirmed that the format is the same
• no Rust write parser for .DS_Store (there seems to only be a rust create to read it, but not write)
• reports that Finder doesn't flush the file immediately, so you'd miss restoring latest trashes
  • this might only be relevant for restore, not delete? Or is there a risk of silent corruption when both your lib and Finder write to the file?

Alternatively you could do something like what's been implemented in this Python script: delete all the files using Rust std FS directly, and save the original paths as xattr metadata for later restoration and restore using that same metadata? Or maybe even write your own custom file format somewhere

[Byron]

Thanks for summarising the current state of trashing on MacOS.

Alternatively you could do something like what's been implemented in this Python script: delete all the files using Rust std FS directly, and save the original paths as xattr metadata for later restoration and restore using that same metadata? Or maybe even write your own custom file format somewhere

It seems that no matter what is done, no choice is really without its issues. From what I can tell, the best would be if one could re-implement everything the Finder does, including writing correct .DS_Store files. In theory, once that works, it should keep working as they won't break backward compatibility, right… right?

The way of the python script I wouldn't want to go, personally, but I see the possibility of 'choosing' which implementation to use by means of cargo features. That way, the application developer can pick their poison.

And if that's a thing, everything is possible - it just wouldn't ever replace the current implementation which is slow but most compatible.