linux-ext4 - Re: Restoring filenames from partly damaged ext4-filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Feb 2012 23:17:17 +0100
From:	Bernd Schubert <bernd.schubert@...tmail.fm>
To:	Ted Ts'o <tytso@....edu>
CC:	Rudolf Zran <rudolfzran@...oo.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"debian-user@...ts.debian.org" <debian-user@...ts.debian.org>
Subject: Re: Restoring filenames from partly damaged ext4-filesystem

On 02/10/2012 10:32 PM, Ted Ts'o wrote:
> On Fri, Feb 10, 2012 at 06:36:52PM +0000, Rudolf Zran wrote:
>>>> * "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long time.
>>>>    Filesystem is mountable. Root is empty besides lost+found folder, which
>>>>    contains about 300GB mostly useless data: Millions of files with wrong
>>>>    permissions, useless names and some random content.
>>
>>> I'd do this by making a copy of the file system first, of course….
>
> I would have expected at least some subdirectories from your directory
> hierarcy that contained useful content.
>
> Just to set expectations, things that you might do that tried to look
> for directory blocks, etc., *might* give you more useful filenames as
> opposed to random inode numbers in lost+found, but it's unlikely to
> recover any more *files*.  It sounds most of your files were located
> in part of the inode table that got smashed, and so short of looking
> at each data block to find useful bits, I doubt spending a lot of time
> on trying to use or create more recovery tools based on file system
> metadata is likely to result in more data getting recovered.
>

You do not need inode tables to get back a basic directory structure. 
Assigning directory blocks with '.' and '..' and then with real content 
provide the file system structure and also inode-number to name 
translation. Even better would be if secondary blocks also would have 
'.' and '..'.


Cheers,
Bernd
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html