On Fri, Mar 07, 2014 at 04:19:44PM -0600, Stan Hoeppner wrote: > Please reply to the mailing list as well as the individual. > > Note that you stated: > > '...the concentrated part of mine is "Deleted File Recovery"' > > On 3/6/2014 10:02 PM, Yongmin wrote: > > > > Yes! there are no actual file data in journaling part. > > > > BUT, by analyzing journaling part, we can get a Inode Core Information which was deleted. > > In Inode Core, there are many information about the actual data, i.e. start address, file length etc. > > Analyzing the journal code may inform you about structures, but it won't > inform you about on disk locations of the structures and how to find > them. If a file has been deleted, no information about that is going to > exist in the journal for more than a few seconds before the transaction > is committed and the entry removed from the journal. Well, we don't actually "remove" information from the log. We update pointers that indicate what the active region is, but we never physically "remove" anything from it. IOWs, the information is in the journal until it wraps around and is over written by new checkpoints.... > > By using those information, Recovering delete file can be done. > > > > So the analysis of Journaling part is absolutely needed. > > I disagree. Again, the journal log is unrelated to "deleted file > recovery" in a forensics scenario. > > I think Dave and Jeff both missed the fact that you're interested only > in deleted file recovery, not in learning how the journal works for the > sake of learning how the journal works. Oh, no, I saw it and didn't think it was worth commenting on. I think it's a brain-dead concept trying to do undelete in the filesystem. "recoverable delete" was a problem solved 30 years ago - it's commonly known as a trash bin and you do it in userspace with a wrapper around unlink that calls rename(2) instead. And then "empty trashbin" is what does the unlink and permanently deletes the files. Besides, from a conceptual point of view after-the-fact filesystem based undelete is fundamentally flawed. i.e. the journal is a write-ahead logging journal and so can only be used to roll the filesystem state forwardi in time. Undelete requires having state and data in the journal that allows the filesystem to be rolled *backwards in time*. XFS simply does not record such information in the log and so parsing the log to "undelete files by transaction rollback" just doesn't work. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
