Nathan Kroenert wrote:
Anyhoo - What do you think the chances are that any application vendor
is going to write in special handling for Solaris file removal? I'm
guessing slim to none, but have been wrong before...
Agreed. However, to this I reply: Who Cares? I'm guessing that 99% of
the possible use of the feature is what people keep talking about, which
is accidentally typing "rm" on something. So, if you fix "rm" and
possibly "nautilus" to use the application-layer RecycleBin, then you've
pretty much satisfied everyone - people like me who don't want unlink(2)
hijacked and don't want most apps to use "undo", and people who want
"oops-proof" 'rm' capability. If we have a standard library which
provides application-layer RecycleBin features, then any app-vendor can
do it if they so choose. I suspect that very few will, but the few who
do will have FILESYSTEM-AGNOISTIC RecycleBin. So we get it for UFS, ZFS,
NFS, Samba, LOFS, and everything else.
On the other hand, who hasn't removed something and thought to
themselves "dang. I wish I could get that back right now..."
As a frequent ex-user of the good old Netware Salvage, I can tell you
I'm a real fan of that type of functionality.
Delete something, but it's not actually *really* deleted until we need
that space for something else. At any point, you can fire up the salvage
utility and grab the files back out of that directory.
It was not perfect either, but, it was wayyyy faster than having to get
tapes out...
The problem of _easy_ recovery of accidentally deleted files is a SMPSA
(Simple Matter of Proper System Administration). The AFS implementation
at MIT had a nice feature: in everyone's home directory, there was a
.afs/backup directory. It contained what would now be known as a
snapshot of last night's backup. Having that around solved 90% of the
accidental deletion problems, since the main issue usually involves easy
access to the recovery media. This kind of setup is trivial to
configure in the current ZFS.
In the case of taking a snapshot before some mythical event that looks
like it's going to seriously change the system, where do we draw the
line? What do we do when we get something like a
for i in *
do
rm $i
done
You want a 100% solution, but is your 100% solution my, or anyone elses
100% solution?
The original problem as stated isn't the whole problem domain, so when I
say 100% solution, I mean the solution to the (reasonably restricted)
general case, which in this instance is "I want to be able to recover
any file previously deleted". .
Snapshots aren't a solution to the problem. They're useful as a recovery
strategy, but aren't a solution, and if I implied so, then I didn't mean to.
I for one, would *much* prefer the filesystem to make that stuff
available to me, so regardless of what removed the file, I at least have
a chance to get it back.
Then again, I'd also much prefer that the files be recoverable right up
until we need the space back. Something like what Eric had suggested,
but set the space that the deleted files *cannot* use, so we still
always have 'free' blocks ready for new allocations...
But, once again, you get into the half-solution of
"some-files-are-available-for-some-time". There are clearly far too many
likely scenarios which will blow through any delete file repository
UNLESS you require that the deleted files NEVER are deleted until
explicitly done so (e.g. "emptying" the Windows Recycle Bin). And,
there again, we're back to 'oh, did I _really_ mean to do that?' And,
people are going to be upset (and complain that the feature doesn't work
right, etc..) if we implement "undo" with some sort of auto expiration
(either limit total size, or whatever). Mainly because they're not
going to understand the limitations.
And, as I pointed out before, it leads to lazy administrative practices.
Turning on an "undo" for everything at the filesystem level is a
nightmare waiting to happen.
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
