Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Apr 2004 17:43:30 +0300 (EEST)
From:      Jari Kirma <kirma@cs.hut.fi>
To:        freebsd-chat@freebsd.org
Subject:   Shadow filesystems [was Re: Pair donates 20,000 to Poul-Henning Kamp??]
Message-ID:  <Pine.GSO.4.58.0404161725410.24624@hutcs.cs.hut.fi>

next in thread | raw e-mail | index | archive | help

> Hmmm... that's a coincidence.  Is this the same sort of thing as the
> 'Shadow Drive' function under Windows 2003?  That is, a system that
> keeps backup copies of files etc. over time, so if you happen to
> accidentally delete something you shouldn't have, you can resurrect it
> without having to go running to your Sys-admin to beg them to get it
> back from the backup tapes.  Sounds conceptually like a slightly more
> elaborate version the old VMS file versioning thing, or the GNU
> numbered backup trick you can do with emacs etc.

I played with the idea of "reliable undelete" functionality some time ago.
The essential idea was to reduce those unfortunate cases where a user has
created large amounts of creative stuff (in university, that'd be code,
essay or something like that at the last minute before the deadline:), and
being tired after all work, fumbled and deleted the work in some
unbelievably idiotic way. There wouldn't be a trace of it in backups,
because the file was created after last backup snapshot and deleted before
the next, so, only something like "reliable undelete" would do the work,
and probably do it in 95% of those different stupid errors.

The main idea was to hook unlink/rename routines so that in some way
controlled cases they would actually either move the file to be removed to
certain location and a userland daemon would be notified to handle it
further, or the file handle would be given to the daemon in some magical
way and kernel would wait it to move it. One more addition, hooking of
truncate/ftruncate to zero would provide some protection against cp, but
that would be more complicated to implement.

In essence, this would provide versioned files, although strangely the
versions would be snapshots of files at their destruction time... and it
wouldn't matter if file existed for a month or a second, version would be
generated if wanted. Of course, context switching and disk updates would
probably increase, as well as file systems getting filled, and potentially
more fragmented due "delayed unlinks."

-kirma



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0404161725410.24624>