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. 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 below. > > I think the directory entries may be recoverable in most cases, as long as > more files weren't added to the directories after the deletes were done. Yes, they are, but unfortunately the two least significant bytes of the inode number get overwritten during deletion, i.e. the inode number is effectively lost. That means you will know that a certain filename did exist, but you don't get much further from there. For details, have a look at the paper I wrote about JFS forensics, available at http://www.xs4all.nl/~eknut/ForensicsForAdvancedUNIXFilesystems.pdf Directory entry journal items can bridge that gap, as is explained in more detail there. Another option of getting to the inode numbers is guessing, since there is typically a bit of locality in inode numbers, i.e. files created in the same directory around the same time often have inode numbers close to each other. >> 2) alter the inodes of deleted files from "deleted" to "not-deleted"? (I >> think this is 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 really 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. >> Any suggestions would be greatly appreciated. Thank you in advance. You can get a snapshot of my current development code, as described in the linked message below. > This is a year old, so I don't know if there has been any progress on this, > but you may want to contact Knut and ask about the status of jfs support > in sleuthkit: > > http://oss.software.ibm.com/pipermail/jfs-discussion/2003-December/001551.html > > There is progress in that directory entries can now be parsed (not recursively yet though) and that I got to document and test my work (see abovementioned PDF article) but not official integration yet. That is planned for sleuthkit 2.0 which will feature some enhancements to facilitate the integration of support for 64bit file systems like JFS. At the moment I use a few slightly ugly patches to support 64bit entities like inode numbers etc. in JFS for Linux. Cheers, Knut _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
