On 3/7/14, 8:08 PM, Stan Hoeppner wrote:
> On 3/7/2014 5:09 PM, Dave Chinner wrote:
>> 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
> Quite right. I sacrificed some technical accuracy to drive home the
> larger point, that the journal shouldn't be relied upon for forensic
> retrieval of deleted files.
>>>> 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.
> Sometimes context gets lost. In his first paragraph he stated he's a
> graduate student and his research area is digital forensics. So the
> discussion about "deleted file recovery" needs to be in the forensics
> context. As you explain above, and as Greg Freemyer pointed out,
> looking at filesystem metadata or journals for information that will
> assist in the recovery of previously deleted files is usually not going
> to be fruitful.
Well, I think that's a good point. "Looking at the log to see if there
are any clues for manual recovery" is a very different problem from
"Use the log for automated, guaranteed successful undelete" :)