> I suppose I'm a bit late on this one but.. Wouldn't it be best to
> implement undelete in user space using a new rm? One could write it so
Yes ... but there are more ways to delete than just "rm". Lots of programs
can delete. rm, cp, mv, redirection of output, any compiled program that
contains code to open a file in write mode.
Which brings another point: how widely interpreted would the "undelete"
thing be? If I have a database program which modifies a file, should it be
backed up? What if I open a file, lseek to the beginning and start writing?
If I append to a file, it seems like it shouldn't back it up. (myriad log
files clogging every pore of the hard drive.) But this can be done by
lseeking to the end and writing -- can the kernel/libc distinguish these
different actions (lseeking to the beginning/middle/end) in time to do the
"right thing"? Should undelete behave like fork()ed memory and
write-on-copy when something is modified? What if I move a file over
another. What if I call a program like "recode" in not-filter mode and it
clobbers the data?
BTW what is meant by a journaling filesystem? Is this a filesystem that can
be "unwound" to the state it was in at some previous time, or is this a
filesystem that stores enough info on what it is doing beforehand to
recover from any error?
__kmb203@psu.edu_________________________Debian__1.1___Linux__2.0.0___
Pascal, n.: A programming language named after a man who would turn over in
his grave if he knew about it.