Can't implement `list`, `purge_all`, and `restore_all` on MacOS

[ArturKovacs]

It seems that there's no publicly available API on MacOS that is needed to list the contents of the trash and to permanently remove or restore items from the trash. These would be needed for list, purge_all, and restore_all accordingly, which are the features planned for version 2. These all may be possible to implement by parsing and editing the DS_Store file but as its structure is proprietary, I wouldn't want to take that approach.

All the three aforementioned functions and thereby all the added functionality of version 2 is currently implemented for both Windows and Linux. To allow users to take advantage of the new functionality on those platforms, version 2 will be released but it won't provide those functions on MacOS.

[NilsIrl]

Regardless of whether it is possible to implement these features on MacOS, I think that the current API (for v2) with restore, purge and list behind the linux_windows module is a bad idea.

[NilsIrl]

I don't know if you've seen this, but it may be able to help: https://stackoverflow.com/questions/18707618/put-back-items-from-trash-programmatically

[ArturKovacs]

Regardless of whether it is possible to implement these features on MacOS, I think that the current API (for v2) with restore, purge and list behind the linux_windows module is a bad idea.

Why do you think it's a bad idea and what would be the alternative you'd propose?

I don't know if you've seen this, but it may be able to help: https://stackoverflow.com/questions/18707618/put-back-items-from-trash-programmatically

Hmm I actually don't remember seeing this. It does look promising but I don't have access to a Mac so I won't be able to work on the Mac implementation right now.

I appreciate your interest in this crate and I will spend some time making sure that at least the Windows and Linux implementations are adequate and I will merge those into the master once there's an agreement on how Macs should be handled.

[NilsIrl]

what would be the alternative you'd propose?

please refer to #13

I appreciate your interest in this crate and I will spend some time making sure that at least the Windows and Linux implementation

Do not feel obliged to do anything. The only reason I'm here is because the only trash implementations I could fine are written in python and bash.

making sure that at least the Windows and Linux implementations are adequate

If there's anything that I can help with let me know.

I don't have access to a Mac so I won't be able to work on the Mac implementation right now

I don't either so, I won't be able to help for this.

[cjbassi]

I can spend some time going through the Linux implementation on the dev branches to make sure it looks good. Can you explain the differences between the 3 dev branches?

Also, I'm sure we can figure out some way to get macOS to work eventually, so maybe it would be good to try to merge those branches ASAP so they don't continue to get left behind if either the Linux or windows implementation is ready to be merged.

[ArturKovacs]

v2-dev is the main development branch. If you would like to contribute to version 2, make a PR agains this branch. v2-linux is where the linux (freedesktop.org Trash) implementation of v2 gets made and v2-mac is where the macOS implementation of v2 gets made.

I can spend some time going through the Linux implementation on the dev branches to make sure it looks good.

That would be appreciated. I'd like to ask you to estimate the objective value when considering to make a PR. Reviewing and discussing PRs is time consuming so try to make sure that the added objective value is worth the effort to process the PR.

maybe it would be good to try to merge those branches ASAP so they don't continue to get left behind if either the Linux or windows implementation is ready to be merged.

Unfortunately the windows implementation can't be merged because it is to this day waiting on a PR for winapi to get merged. This one to be exact: retep998/winapi-rs#834

If you'd need version 2's features for macOS urgently I can make an attempt at an implementation but otherwise I'm really quite buisy with other stuff.

[urwrstkn8mare]

Since osascript is already used, I think this might be promising:
applescript-finder-guide.pdf (see PG91: Trash-Object)

I don't have a mac right now, so I can't play around with it, but hopefully I can set up a VM or something along those lines.

[urwrstkn8mare]

Alr well I didn't get far with that but I managed to get some info from .DS_Store (original file loc) and the rest I can get from finder I'm assuming.

The issue is that with MacOS Put Back feat alr being a little buggy Finder the .DS_Store file being up to date is also a little buggier. (Mainly sometimes the file will lag one trash action behind. For example when u move a file to trash it might not show up in the file but after moving another file the first file will show up but not the second)

This makes using the file to implement list() produce sometimes incomplete results.

I see several options:

1. Implement it and accept the bugginess on MacOS's side. (Probably will have to allow some fields to be null)

2. Implement it but basically do the work of the os if the os doesn't do it. Basically this involves updating the DS_Store ourselves if Finder does not. This means writing a new .DS_Store reader and writer library. (Note that changing the file doesn't change any functionality of Put Back as it seems Apple doesn't depend on .DS_Store anymore but still keeps it around for legacy purposes I'm guessing.) Which is why the Put Back button can be available but the file loc isn't visible in the .DS_Store.

3. Forget it, leave it until the future if Apple ever decides to make any sort of API for this.

[Byron]

Thanks for the analysis and the writeup, it's much appreciated!

I wonder if there are ways to mimic what the OS is already able to do and get a working implementation that way. After all, the .DS_Store file seems to be broken enough to rather not use it.

Mimicking the OS could work if it solely relies on files on disk that could be read, maybe easily, maybe with some reverse engineering. If MacOS doesn't really seem to care about .DS_Store, why should we? That could be option 4.

[urwrstkn8mare]

Agreed. How to even begin to reverse engineer Put Back is beyond me. Despite that I'll give it a go but if anyone knows at least where to begin that'd be nice and I'll help however I can.

[ArturKovacs]

My opinion is that it's not worth the effort reverse engineering this feature, as the OS's implementation might change at any point, especially because it is undocumented.

Only implementing list (and restore) with an AppleScript (as @samit43, you suggested) would be a more reasonable approach, if that's possible. If that's not possible then I would wait for Apple to create some sort of API for these things.

[urwrstkn8mare]

Yep totally agree, upon I've quickly realised that for me reverse engineering this is borderline impossible and plus very susceptible to be broken by any update.

Looking at the applescript docs I think it may be possible but to be honest I don't understand the details enough to make it work. There is a Trash structure with many properties but I don't know how to even access them. I invite anyone with more experience to give it a go but other than that sorry for not really accomplishing anything.

[bestlem]

See https://github.com/ali-rantakari/trash for a C version of using Finder to trash the file which provides the Put Back Information