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 ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel