Date: 06 Jun 2000 00:14:07 +0200 From: Juergen Nickelsen <jnickelsen@acm.org> To: Anatoly Vorobey <mellon@pobox.com> Cc: chat@FreeBSD.ORG Subject: Re: Undelete in Unix (Was: Re: Why encourage stupid people to use *BSD) Message-ID: <x7d7lvlqs0.fsf@goting.jn.berlin.snafu.de> In-Reply-To: Anatoly Vorobey's message of "Mon, 5 Jun 2000 16:20:25 %2B0300" 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. And, of course, a wrapper for the unlink(2) and rmdir(2) system calls to catch other programs than just rm(1). 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. 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. Besides the well-known "rm * .o" kind there are also errors like "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? True story: 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 *~ -- without a terminating newline. Oops. Yes, he DID complain. (That was the shape(1) program of the shapeTools SCM tookit. I re-implemented the parser the same year and made *very* sure I wasn't hit by the same bug.) -- Juergen Nickelsen 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?x7d7lvlqs0.fsf>