Re: Any way to undelete files from jfs partition?
On Tue, 2004-12-14 at 00:21 +0100, Knut Eckstein wrote:
> Hello all,
> >> 1) use the JFS journal to roll back all transactions past a certain time
> >> index?
> > It would be possible to do this in many cases, since a lot of the
> > information you need can be reconstructed from the journal. It wouldn't be
> > reliable in all cases, in that you would be able to reconstruct what disk
> > blocks were allocated to a file, but I'm not how easily you could determine
> > the logical file offset of these blocks. That information may still be
> > available in the inode, but I'm not positive. I don't think there's any
> > way to recover the size of the file (other than an estimate, based on where
> > the last extent is).
> IMHO, the logical offset of a disk block should be visible, since it is
> part of struct xad_t and as such it should be possible to find it
> in a journal entry that contains extent allocation changes in an inode.
> That same entry should also hold the filesize, since it is a member
> of struct jfs_inode.
The journal will only contain the parts of the inode that have been
modified, so it probably won't contain all of the xad entries, but as
long as the inode was not re-used, this metadata is still intact in the
inode. I was completely wrong when I stated below that the inode is
truncated when it is deleted.
> I'm saying 'should' because I have not examined those types of journal
> entries yet. I've been focusing on directory entry journal items, see
> >> 2) alter the inodes of deleted files from "deleted" to "not-deleted"? (I
> >> think this i...
s how undelete utilities for other filesystems (such as ext2)
> >> work.)
> > The files are truncated as they are deleted, so only doing this would give
> > you empty files (with no path to them). There might still be enough
> > information in the inodes to reconstruct the xtree, but you'd have to
> > determine the number of extents to try to recover, and wouldn't really have
> > an accurate file size.
> >From what I've seen with my JFS module for sleuthkit, the files are not
> truncated, but just marked as deleted, i.e. the file size and the full xtree
> (including xtree parts not stored inside the inode) can be seen with the istat
> tool. That means that once you know the inode of the deleted file you are
> looking for (either by guessing or by looking at journal entries), you can use
> icat to undelete that file, if the following three conditions are met:
> 1. The inode you are looking for has not yet been reused
> 2. "External" xtree blocks (in case they were required to
> describe the exact allocation of that file on disk) have
> not yet been overwritten
> 3. The disk blocks containing the actual file have
> not yet been
> reused for another file or metadata.
Yeah, thanks for correcting me. The "truncation" that is done at
deletion time only marks the disk blocks as available. It doesn't alter
the inode (other than di_nlink) or xtree structure.
Thank you, Knut. I haven't read your paper yet, but I will.
IBM Linux Technology Center