linux-ext4 - Re: e2fsck repeatedly asks to clear the same entry?

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] [day] [month] [year] [list]

Message-ID: <50B2E762.5040906@unifiedgroup.com>
Date:	Sun, 25 Nov 2012 21:52:02 -0600
From:	Mark Casey <markc@...fiedgroup.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: e2fsck repeatedly asks to clear the same entry?

On 11/24/2012 1:17 PM, Andreas Dilger wrote:
>
> So this is the problematic entry. The directory entry looks ok, though it doesn't have the same name as e2fsck reports. It claims the entry is "A5 11-3", which is a bit bizarre.

My fault. I was initially inconsistent in deciding what parts of our 
real tree I wanted online. So there is nothing named "A5 11-3". Should 
not be an issue again; sorry to add complication.

>
> ...
>
> Yes, though if this directory is accessed it might turn the filesystem read-only.

Yep, it does.

>
>> These files are older so I wouldn't mind setting the permissions so that no one can get to them for a bit. What would I need to do to get a test case going?
>
> Just mark the parent directory inaccessible:
>
> # chmod 000 "/share/path/09/Brett/Pines/Flynt's Side Drive - Complete Archive Copy/SA Version Pines/Chris Pics 11-2-10/Group 5 11-3"
>

No problem. Once I've got that done I'll see what I can do with e2image. 
I really appreciate the input so I'd like to do whatever I can if you 
still think it might lead to some sort of bugfix. So far the only 
changes made were to restore the other files that the post-resize fsck 
had to remove/free. Final total was a couple gigs across 7 dirs.

I've looked for any stat differences between the current file tree and 
the one from the backup just before the resize. The only issue found is 
that there appear to be ~200 directories that were not removed by fsck 
but appear to have had their modtimes reset by it instead. The actual 
files contained were untouched. If that is also no big concern then I 
think later tonight, after/if I can get an e2image done, I'll just 
restore their modtimes from the backup to make things pretty again.

Thank you,
Mark

--
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