Trash management

I've been thinking about how trash management might translate to WASI and wanted to layout a few sticking points that I can see WASI potentially running into.

Rational

For why I think this is worth considering see this excerpt from the FreeDesktop.org's Trash specification document (worth reading).

An ability to recover accidentally deleted files has become the de facto standard for today's desktop user experience.

Users do not expect that anything they delete is permanently gone. Instead, they are used to a “Trash can” metaphor. A deleted document ends up in a “Trash can”, and stays there at least for some time — until the can is manually or automatically cleaned.

This system has its own problems. Notably, cleaning disk space becomes a two-step operation — delete files and empty trash; this can lead to confusion for inexperienced users (“what's taking up my space?!”). Also, it is not easy to adapt the system to a multiuser environment. Besides, there is a potential for abuse by uneducated users — anecdotal evidence says they sometimes store important documents in the Trash can, and lose them when it gets cleaned!

However, the benefits of this system are so great, and the user expectation for it so high, that it definitely should be implemented on a free desktop system. And in fact, several implementations existed before this specification — some as command line utilities, some as preloaded libraries, and some as parts of major desktop environments. For example, both Gnome and KDE had their own trash mechanisms.

https://specifications.freedesktop.org/trash-spec/trashspec-latest.html#Introduction

Issues

Without digging too deeply into the problem it would be easy to think that trash management in WASI could purely be handled by adopting a set of conventions for how files should be trashed and restored. The above FreeDesktop.org specification document details how applications should provide a common way of exposing a trash system to end users and part of their solution is to adopt a set of naming conventions for trash folders. Windows also has it's own set of assumptions when it comes to it's recycle bin.

However simply adopting a convention only gets you so far and there are aspects to trash management that require some understanding of the physical mapping between directories and storage devices / partitions.

• Trashing a file that exists on an external drive should ideally avoid copying the file to another physical drive. This would require that WASI know which directory maps to which drive and what the "root dir" for a particular directory is so that it can find the correct ".trash" folder.
• In multi-user systems trash folders may contain a separate trash folder for each user. WASI may then need to know the current user id to then pick the correct trash location.
• Trashing folders normally have size restrictions and settings surrounding automatic deletion of old files.

WASI also has the opportunity here to define its own trash specification to avoid the mess that comes with a naming convention approach. Possibly trash settings should be set on the WASI runtime at startup, Possibly the trashed files shouldn't be stored in the same filesystem tree that gets exposed to WASI.

I don't have answers to these questions but if ignored then I imagine applications built on top of WASI will have a hard time implementing "file trashing" functionality to the same level as a native app. If someone wanted to write a file manager in WASI, how can they support file trashing for external devices? Should file trashing be compatible with the host systems file trashing logic? Should multiple WASI apps share the same trash bin?

Start by reading the linked FreeDesktop.org Trash specification and the WASI issue's questions about external drives, users, storage limits, and runtime settings. Done would mean reaching agreement on whether WASI should define trash-management semantics and documenting the resulting behavior or specification.