This is before my time, but I believe the original intent was that
deleted files would be preserved for some length of time - space
reclaimed only when needed or when they got "old enough" - so you
could undelete things without having to grovel through the raw disk.
That was never implemented as far as I know. See NetWare for a
similar idea.
There was some thought to doing this, but the main reason for dtime is
that it makes it much easier to undelete a file using debugfs. See
debugfs's lsdel command; using it you can determine which of the deleted
inodes in your system is the one which you probably should look at
trying to recover the data.
All you need to recover the data from inode #12345 is to use the debugfs
command "dump <12345> /tmp/saved-file". Just make you write saved-file
data to a filesystem other than the one where you're trying to recover
deleted files.
Interestingly, there *is* no special handling of dtime in ext2fs: it's
set and the inode is marked dirty just like any other inode update.
So why is it, I wonder, that fsck always complains about deleted
inodes with zero dtime but rarely if ever about other inode
inconsistencies?
The dtime field is set a file is unlinked, but when the inode is
reclaimed. If a file descriptor is open on that inode, there may be a
significant amount of time between when the last reference to that inode
is removed from the filsystem, and when the inode is actually deleted.
If the system crashes while the inode is still in use by some file
descriptor, the dtime field will be zero, but the link count on the
inode will be zero as well, and this causes e2fsck to issue a warning
message. Fortunately, it's both harmless and the most likely filesystem
inconsistency found when a system is brought down uncleanly. Of course,
if filesystem updates were in progress when the system crash, things
could be worse. But that doesn't happen all that often.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/