> The author implies that his code may have bitrotted.  Apple in
> particular keeps the metadata in a binary file whose format is not
> documented.  What's more, the formats are all very vulnerable to failure.

I'm using that specific library on Mac and it works fine. It has to be
done by calling OS APIs, not by writing to the trashcan's datastore
ourselves. In addition to moving trashed files into the datastore, the
OS APIs may do other stuff like trigger notifications, etc.

> If we are going to do this, I'd rather have our own portable trash can
> service, even though it would be incompatible with the various system
> trash cans.  A trash directory for each volume (read the output of
> `mount`, or on Windows, enumerate al local disks, everyone does that.
> But then store the files directly in it with a SQLite database to hold
> the metadata.

The trashcan is meant for the convenience of desktop users so that all
applications put their trash in the same system-wide place (e.g. the
trashcan icon in the MacOS Dock and the Windows Desktop - GNOME and KDE
probably have equivalents). The desktop provides a conventional icon
that users can click to list everything in the trash and have the option
of restoring individual files.

 From that background I would oppose any custom solution, no matter how
cleanly implemented it is. We want to eventually enable Schemers to
write desktop apps with a native look and feel. That means we should
conform to native conventions in these matters as well.

(Similar remarks apply to the clipboard - we should call the system APIs
to call whatever the system clipboard is. Maybe a clipboard-and-trashcan
SRFI would make for a good combo since those APIs are both simple and
called by similar means yet deeply system-dependent.)

But all this pondering has made it clear that trashcan stuff is
definitely outside the scope of fundamental OS SRFIs. There is a clear
need to keep "OS" and "desktop" procedures separate.