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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
