On Thu, Jan 20, 2005 at 11:59:11AM +0100, Walter Hofmann wrote:
> Dear Ted,
>
> I have now finished preparing the image file you requested. It is
> attached to this mail. I have a number of remarks:
>
> - the output of e2image was one byte longer than the device -- I think
> you need to remove this last byte before continuing
It's fine; the extra byte doesn't hurt anything.
> - e2image -s failed to scramble some file names (besides fast symlinks).
> Also, I found some data blocks in the image. I overwrote everything
> with the string "cleaned" (repeated). Also, there are a number of
> occurencies of "index.html" in the image. I didn't bother to overwrite
> these.
Hmm.. I don't know how that had happened; I'll have to investigate
that. Looking at the code, I'm guessing the data blocks either came
from long symlinks (which e2image -s isn't zeroing out, but should) or
from the extended attribute blocks. I'll have to find the blocks with
the "cleaned" string, determine their block numbers, and see how they
were being used in the filesystem.
I've investigated the file you sent me, and it was very helpful
indeed, thanks. What is going on is that when a filesystem is resized
enough so that we need to move the inode table, we reserve both the
old and new locations of the inode table. However, we aren't
releasing the blocks where the inode table used to be located after
the resize. So this isn't a fatal error, in that it doesn't cause any
data loss; the next e2fsck will release the blocks.
I'm rather surprised no one has noticed this before, actually....
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
