Image einer NTFS-Partition verhält sich anders als die Partition selbst

Herr_Krolik · 16.10.08, 20:56

Liebe Forumsmitglieder!

Nach dem Tod eines alten Notebooks (Motherboard war unwiederbringlich kaputtgegangen) wurde ein neues Laptop gekauft, auf dem jetzt ein Dualboot-System (mit Vista und Ubuntu 8.04) angelegt ist. Die kleine 2,5 Zoll Festplatte von dem alten NB scheint trotz allen Befürchtungen gerettet zu sein und kann (mittels IDE/USB-Adapter) unter Linux gemountet werden. Um die alten Daten von der NTFS-Partition (/dev/sdc1) sauber zu retten, habe ich nun wie folgt gehandelt:

1. Die gemounteten Partitionen der alten Festplatte Sicherheitshalber aushängen

Code:

myname@SARTAN:~$ df | grep sdc 
/dev/sdc1              5118088   4607809    510279  91% /media/disk 
/dev/sdc4              2217480   1275920    828916  61% /media/disk-1 
/dev/sdc3              2267924   1769252    498672  79% /media/disk-2 
myname@SARTAN:~$ sudo umount /dev/sdc1 
[sudo] password for myname: 
myname@SARTAN:~$ sudo umount /dev/sdc3 
myname@SARTAN:~$ sudo umount /dev/sdc4

2. Entsprechend dem Artikel http://groups.google.de/group/ch.com...977f6f8bc994c3

Code:

myname@SARTAN:~$ ls -l /dev/sd 
sda   sda1  sda2  sda3  sda4  sda5  sda6  sda7  sda8  sdc   sdc1  sdc2  sdc3  sdc4  
myname@SARTAN:~$ sudo dd if=/dev/sdc1 bs=512 conv=noerror,sync | gzip -1 > /home/myname/Bilder/PRINZESSIN_sdb1.gz 
dd: Lesen von „/dev/sdc1“: Input/output error 
2912+0 Datensätze ein 
2912+0 Datensätze aus 
1490944 Bytes (1,5 MB) kopiert, 5,40569 s, 276 kB/s
...
1555456 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s 
dd: Lesen von „/dev/sdc1“: Input/output error 
2912+127 Datensätze ein 
3039+0 Datensätze aus 
1555968 Bytes (1,6 MB) kopiert, 84,0148 s, 18,5 kB/s 
10236049+128 Datensätze ein 
10236177+0 Datensätze aus 
5240922624 Bytes (5,2 GB) kopiert, 1706,97 s, 3,1 MB/s

3. Image wird auf die große Partition der neuen Festplatte (/dev/sda8) entpackt und gemountet

Code:

myname@SARTAN:~$ gzip -cd Bilder/PRINZESSIN_sdb1.gz > /media/Common/PRINZESSIN_sdb1
myname@SARTAN:~$ sudo mount -o loop /media/Common/PRINZESSIN_sdb1 /media/sdb1
[sudo] password for myname: 
myname@SARTAN:~$ mount | grep 512
/dev/sdc1 on /media/disk type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)
/dev/loop1 on /media/sdb1 type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=512)

4. Inhalt eines Dateiverzeichnisses im Image ("Eigene Dateien") wird zu Testzwecken gelesen

Code:

myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root   45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
ls: lese Verzeichnis /media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/: Input/output error
insgesamt 0

5. Inhalt desselben Dateiverzeichnisses der alten Festplatte lässt sich aber problemlos auf das Terminal ausgeben

Code:

myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/ | grep Dateien
drwxrwxrwx 1 root root   45056 2008-06-30 12:56 Eigene Dateien
myname@SARTAN:~$ ls -l /media/disk/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
insgesamt 2123
-rwxrwxrwx 2 root root  10164 2003-04-20 15:16 AGB_WEB.Cent.txt
-rwxrwxrwx 2 root root  12219 2003-04-20 15:05 AGB_WEB.DE.txt
....
-rwxrwxrwx 2 root root    663 2006-11-30 00:46 ZIPDaten_LinuxPartition.txt

6. Mit Hilfe von strace wird nun versucht die Gründe des ls-Absturzes zu erforschen

Code:

myname@SARTAN:~$ strace ls -l /media/sdb1/Dokumente\ und\ Einstellungen/Sergej/Eigene\ Dateien/
execve("/bin/ls", ["ls", "-l", "/media/sdb1/Dokumente und Einste"...], [/* 34 vars */]) = 0
brk(0)                                  = 0x805f000
...
lstat64("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
lgetxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "security.selinux", 0x8068b20, 255) = -1 EOPNOTSUPP (Operation not supported)
getxattr("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
...
open("/media/sdb1/Dokumente und Einstellungen/Sergej/Eigene Dateien/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3
fstat64(3, {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents64(3, 0x806a860, 512)           = -1 EIO (Input/output error)

Trotz den durchgeführten Schritten bleibt mir unklar, wieso der ls-Befehl abstürzt, wenn er auf das Image zugreift, tut es aber nicht, wenn er auf die Originalpartition (auf die alte Festplatte unmittelbar) zugreift? Kommt es auf die Existenz der geschädigten Blöcke in dieser NTFS-Partition oder auf die schlauen Permission bits des getesteten Dateiverzeichnisses an?

Die alte Festplatte wurde schon auch mal unter MS Vista über die USB-Schnittstelle angehängt und mit der Utility chkdsk getestet, welches ausspuckte: "Das Dateisystem wurde überprüft. Es wurden keine Probleme festgestellt."

Für weitere Kommentare und Ratschläge bin ich im voraus sehr dankbar.