Date: Tue, 6 Jun 2000 04:24:12 +0300 From: Anatoly Vorobey <mellon@pobox.com> To: Juergen Nickelsen <jnickelsen@acm.org> Cc: chat@freebsd.org Subject: Re: Undelete in Unix (Was: Re: Why encourage stupid people to use *BSD) Message-ID: <20000606042412.A43514@happy.checkpoint.com> In-Reply-To: <x7d7lvlqs0.fsf@goting.jn.berlin.snafu.de>; from jnickelsen@acm.org on Tue, Jun 06, 2000 at 12:14:07AM %2B0200 References: <3939F26A.A405DD4A@mail.ptd.net> <LPBBJIAAFFNFMKJGNIAIIEBJCAAA.keramida@ceid.upatras.gr> <20000605081334.C25970@ecto.greenpeas.org> <001501bfceee$34cb9a00$858c8c96@win2000.cc.ceid.upatras.gr> <20000605162025.A32447@happy.checkpoint.com> <x7d7lvlqs0.fsf@goting.jn.berlin.snafu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 06, 2000 at 12:14:07AM +0200, Juergen Nickelsen wrote: > Anatoly Vorobey <mellon@pobox.com> writes: > > > I suppose one way to do it would be to replace rm by the following > > scheme: > > > > - every filesystem holds a .dustbin directory at the root of the > > filesystem; > > - the .dustbin directory includes symlinks of the kind > > .dustbin/originaldir-originalname --> .dustbin/43265 > > > > and hardlinks of .dustbin/43265 to the file with inode 43265. > [...] > > You would also have to handle the case that multiple instances of > the same pathname get removed, so a kind of versioning scheme would > be needed. I'd just use inode as the unique identifier. Thus links in .dustbin will look like origdir-origname-inode-->inode, and inode hardlinked to the actual file. Slashes are encoded in origdir somehow, etc. When looking to undelete origdir-origname, search for origdir-origname-* in .dustbin, and using inode hardlinks present helpful information to the user about sizes, times, etc. of different candidates for undeletion. > And, of course, a wrapper for the unlink(2) and rmdir(2) > system calls to catch other programs than just rm(1). Well, that demands kernel level intervention (because of the static binaries), I was trying to explicitly show something that only uses user-mode code. But yes, simple wrappers for syscalls are possible, which will relegate to user-mode the actual handling, for robustness. > You might want > to have this configurable per file system or per directory > hierarchy, so that large builds with lots of /tmp files don't > clutter your disk space. I agree. Could be a usermode-visible mount option which newrm(1) or syscalls wrappers check. Per-directory configuration seems too bothersome to be worth it, though one can kludge away something like touch $dir/.dontundeletefileshere. > With respect to the versioning scheme: If a directory hierarchy is > rapidly changing for whatever reason, it might be useful to maintain > a log *when* which file was deleted, in order to be able to restore > a consistent state of a certain time in the past. The log is simply there in inode, isn't its access time changed when a directory entry to it is unlinked? If not, it can be made to change. Since the inode is effectively being frozen when the file is "deleted", the only reference to it staying in .dustbin, this information is available later for undeletion considerations. > "echo 'test:*:101:20:test account:/home/test:/bin/sh' > /etc/passwd" > where ">>" was meant. Should the same level of protection apply to > file that are accidentally overwritten? This sounds too complicated. Well, OK, how about this -- catch ftruncate's to zero size, and clone the file in such cases, storing it in .dustbin in a similar fashion to above. Don't even start talking about mmap'ed files, please :) > The parser of a make-like build tool had the bug that it would not > read the last character of the last line of the Makefile if there > was no terminating newline character. Guess what happened: Someone > had a "clean" rule last in his Makefile, like this: > > clean: > -rm -f $(TARGET) *.o core *~ Ouch! Thanks, it was a good one. -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000606042412.A43514>