Jean-Pierre André wrote:
Иван Омельченко wrote:
Following the data you sent (not shown on the list because there
were attachments), I may have found the cause :
> >
> > fs@fs-hpc:~$ sudo head -c 80 /dev/sdb1 | od -t x1
> > 0000000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 40 00 00
> > 0000020 00 00 00 00 00 f8 00 00 3f 00 ff 00 3f 00 00 00
> > 0000040 00 00 00 00 80 00 80 00 c0 57 aa 2d 00 00 00 00
> > 0000060 8e 00 00 00 00 00 00 00 57 00 00 00 00 00 00 00
> > 0000100 f6 00 00 00 f6 00 00 00 60 8d af ef 95 de d4 01
> > 0000120
>
> I see nothing wrong there, though I am surprised that the index block
> size was defined as 1024 (same as with the original 16K clusters).
Nevertheless, the indexes look like they were built with a block
size of 4096 (which is the usual value). In other words, there is
a mismatch between the boot data and the indexes.
In the original partition (with 16K clusters), the index block size
was 1024 and ntfs-3g could use the indexes. So I think Acronis had
rebuilt the indexes using the standard block size, but failed to
update the boot header accordingly.
To confirm this theory, I would first ask you to post the index
of the root directory. This is at cluster 0x896 (sector 140672) :
dd if=/dev/sdb1 bs=512 skip=140672 count=8 | od -t x1
You may also try to fix the boot data : the unexpected value is
0xf6 at octal location 0104 (which is decimal 68). The value for
index block size 4096 is 0xf4.
A possible way for fixing that is :
1) have a temporary file with first byte 0xf4 :
echo -ne '\xf4' > temp
2) insert the byte into /dev/sdb1 at offset 68 :
dd if=temp of=/dev/sdb1 bs=1 seek=68 count=1 conv=notrunc
3) try mounting.
Jean-Pierre
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
