Re: undeletion at filesystem level or in extra filesystem?

[Marcus Brinkmann]

On Mon, Sep 30, 2002 at 04:00:46PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > I wonder, should undeletion (aka the Windows trash can) better be done at a
> > per-filesystem level (like, in diskfs), or with an extra-filesystem that is
> > stacked (like shadowfs)?
> 
> Undeletion, without exact semantics, is a mistake, wherever it is
> implemented...

It's also a feature many users want.  I know that you and me can hex edit
the filesystem by heart when one of us made a stupid mistake.  Another 0.000001%
can find their way with debugfs, dd and a HOWTO, but for the vast majority of
people the files will be lost completely after an unlinking them, even though
they are still intact on disk.  The reason I raised this issue is that I just
saw a news story about libtrash, a library for glibc based systems that is
preloaded and overrides some glibc functions.  _That_ is certainly the wrong
place to implement it, and it is a common pattern that people do this if
what they really would want to do is to enhance the kernel (or its replacement).
See fakeroot, or Gnome VFS, for other examples of this type.

I also worked at a place where I replaced a Novell file server with a
GNU/Linux based solutions, and something like a trash can was pretty much
desired.  People don't care what you call it or what the exact semantics
are.  They just want to be able to undo a mistake made in a hurry.  Sure,
UN*X gives you plenty of ammunition to shoot yourself in the foot.  But
frankly, hex editing the raw filesystem is a painful job to do for a human,
and something that is simple to do for a computer, so if you'd ask me what I
prefer who does it, I would know what to answer right quick.

Now, sure, we can talk about the right semantics.  We can think of
versioning with automatic expiration of old versions, either by time or by
count.  We can talk about making new versions when files are modified or
deleted.  We can keep in mind that keeping files around after they have been
"deleted" is keeping fragmentation up.  We can also think about border
conditions like what you do if the disk simply is full and you can not keep
the data around sensibly (the bleeping dialog box of Windows is certainly
suboptimal).  If there are other semantic categories you are thinking about,
please let us know.

The question still is, after you have found the right semantics, where is the
place to implement it then?  Or are you saying that whatever the semantics,
there is no place to implement that?  Or, another possibility: that the place
to implement it depends on the exact semantics?  It would be nice if your
comment could be more of the inspiring rather than the demotivating type :)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/