Messages in this thread | | | Date | Tue, 17 Aug 1999 19:13:12 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: kupdate & laptop's [patch for integration of mobile-update] |
| |
Date: Mon, 16 Aug 1999 14:42:46 -0700 From: Zack Weinberg <zack@bitmover.com>
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/
| |