fsck для ext4, доступного для 64-разрядных систем?

Во-первых, я хотел бы благодарить James T & ct64116 для их справки по моему первому вопросу; я случайно перезаписал ext4 раздел с установщиком Windows 7 и потерял что-то как 300 ГБ файлов.

Я послушал их совет и использовал испытательный стенд для анализа потерянной файловой системы. Все, кажется, в порядке, и я был возбужден о восстановлении его, но я поразил удар скорости.

Я запускаю Ubuntu 10.04 на 64-разрядном процессоре. Для восстановления файловой системы я должен найти резервные суперблоки (который я уже сделал), и затем используйте их для fsck диск назад в применимое условие. Но это не работает, и я думаю, что знаю почему.

Я использую это учебное руководство для подъема раздела и выполнения. Однако, когда я выполняю fsck.ext4, я получаю другой вывод, чем он. В первую очередь, номера версий отличаются: он имеет 1.41.4, я имею 1.41.11.

Второй из всех, даже при том, что я выполняю fsck.ext4, сообщение об ошибке, которое я возвращаю, говорит мне, что файловая система, которую я исследую, не является корректной ext2 файловой системой.

Таким образом, я думаю, что проблема здесь состоит в том, что версия fsck, который я имею, еще не понимает ext4, и причина, это не понимает ext4 (даже при том, что дата компиляции на моем позже, чем его) состоит в том, потому что я выполняю 64-разрядную систему, и более новый fsck еще не был портирован к 64-разрядному. Это звучит правильным?

Так или иначе, если нет более нового fsck для 64-разрядных систем, я думаю, что моя единственная надежда теперь состоит в том, чтобы взять внешний 3,5-дюймовый корпус, вытащить диск, сцепить его до моего i386 ноутбука и делать попытку восстановления файловой системы от той машины (который использует версию 1.41.9).

Это походит на хорошую идею? Кто-либо знает, существует ли более простой способ зафиксировать это (как, если существует 64-разрядная сборка более нового fsck доступного - я, может казаться, не нахожу много информации через Google - это немного плотно для меня к обзору)?

Благодарит тонну.

SS

править: на совет nik вот вывод fdisk для рассматриваемой системы. В настоящее время подвергаемый опасности диск является последним в списке в/dev/sdc1.
_{[редактирование nik: я удалил данные из других дисков для сокращения помехи - смотрят на предыдущее редактирование, если это требуется]}

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x05ced8ed

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1      182402  1465136128    7  HPFS/NTFS

ОБНОВЛЕНИЕ: у Меня не было удачи с суперблоками; однако я бездельничал с испытательным стендом, и я обнаружил, что испытательный стенд скопирует структуру папок в мой корневой каталог! УРА

Мой корневой каталог находится на SSD, тем не менее, и существует только приблизительно 30 концертов пространства, доступного в любой момент времени, таким образом, я должен буду периодически поражать свои копии и дамп к большему диску - хорошая вещь, у меня есть дополнительный диск доступный жесткий диск. Я просто пройду, папка папкой, пока я не скопировал все данные к другому диску. Это займет время, но намного меньше времени, чем он берет, чтобы пройти и переименовать КАЖДЫЙ ФАЙЛ, который является тем, что я имел бы отношение к photorec.

СПАСИБО ЗА всю Вашу справку, особенно Вы nik.