Return trash items that are created by delete

[jackpot51]

This allows for restoring those files exactly, even if multiple files with the same path have been trashed. I have only implemented this for the freedesktop platform, which is why it returns an Option. Marking as a draft until all possible platforms are supported, or that is deemed unnecessary.

[sungsphinx]

Can this be rebased so deleting files works on Universal Blue/Fedora Atomic Desktops? Thanks.

[Byron]

This has been a draft for a long time and to my mind, there isn't anything holding it back, generally at least.

Some concerns might be memory consumption, as I think that will be quite high with hundreds of thousands items deleted, but I suppose that's not usually what people do and it returns only the top-most level items anyway.

@sungsphinx Please feel free to open a new PR with this work rebased, superseding this one.

[jackpot51]

This is ready, provided the platform availability is okay. I can rebase it if needed

[Byron]

Right, I oversaw that only free desktop is actually implemented, and that tests haven’t been updated either.
From that perspective, I think the PR is indeed not ready and a rebase alone wouldn’t do it.

[eugenesvk]

I've added a Mac's implementation with one change so far: we should return a single item when deleting a single item, not a vec, that's unexpected.

And think this should also be addressed:

Some concerns might be memory consumption, as I think that will be quite high with hundreds of thousands items deleted, but I suppose that's not usually what people do and it returns only the top-most level items anyway.

We could have it both with an extra argument. I think the default should be the simplest one, so I've started splitting functions in two: delete and delete_with_info, where the former is reverted to return nothing, and the latter can be used when trash items are needed.

Though maybe the proper way is for this to be only accessible via trash context similar to how deletemethod on macs work?

[eugenesvk]

By the way, why is the original path stored in parts and requires a separate call to get to that combines sub-parts?

Wouldn't it be better to have a single hashmap keyed by the original path with a (trash_path, delete_time) tuple? The trash_path might be better as key for restoration purposes, but then it's not guaranteed we can get it

Or maybe even better: this could be some trie-type structure that would allow easily answering questions like "what are all the items removed with a path that contains ~\Documents`