[erledigt] Segmentation fault - ntfs-3g - Anwendungen

Anfänger

07.06.2009, 11:50

Segmentation fault - ntfs-3g

Hallo Leute,
ich habe eine externe Festplatte, welche in 2 Partitionen aufgeteilt ist und schon seit ca. 1/2 Jahr ohne Probleme funktioniert. Auf der ersten Partition ist mittels dm-crypt über cryptsetup eine AES Verschlüsselung ein gesichertes NTFS-Dateisystem. Diese ließ sich bis gestern problemlos unter Windows und Linux (ntfs-3g) mounten. Gestern habe ich als letzten Zugriff ein paar Dateien (ca. 2GB) auf die Festplatte kopiert und dann unter Windows normal via Free OTFE geunmountet. Schien alles problemlos zu funktionieren.
Doch als ich dann heute nochmal auf meine externe Festplatte zugreifen wollte, meldete Windows, nach dem mappen der verschlüsselten Partition auf einen Laufwerksbuchstaben,

Zitat

Auf J:\ kann nicht zugegriffen werden.
Die Datei oder das Verzeichnis ist beschädigt und nicht lesbar.

Das Mappen der Partition schien aber ohne Probleme abzulaufen.

Dann uter Linux:

	Quellcode
1 2 3 4 5 6	sonne ~ # cryptsetup luksOpen /dev/sda1 extHDD Enter LUKS passphrase: key slot 0 unlocked. Command successful. sonne ~ # ntfs-3g /dev/mapper/extHDD /mnt/extHDD Segmentation fault.

Damit verabschiedet sich dann ntfs-3g.
Ich habe ntfs-3g dann mal mit debug Useflag kompiliert und jetzt sagt es folgendes:

Quellcode

ntfs_pread(): pos 0, count 512
Beginning bootsector check.
Checking OEMid, NTFS signature.
Checking bytes per sector.
Checking sectors per cluster.
Checking cluster size.
Checking reserved fields are zero.
Checking clusters per mft record.
Checking clusters per index block.
Bootsector check completed successfully.
SectorSize = 0x200
SectorSizeBits = 9
SectorsPerCluster = 0x8
NumberOfSectors = 1855474274
MFT LCN = 786432
MFTMirr LCN = 115967142
ClusterSize = 0x1000
ClusterSizeBits = 12
ClustersPerMftRecord = 0xfffffff6
MftRecordSize = 0x400
MftRecordSizeBits = 10
ClustersPerINDXRecord = 0x1
INDXRecordSize = 0x1000
INDXRecordSizeBits = 12
Used BLKBSZSET to set block size to 512 bytes.
mft_zone_pos = 0xc0000
mft_zone_start = 0xc0000
mft_zone_end = 0x1c66129
data1_zone_pos = 29778217
data2_zone_pos = 0
ntfs_pread(): pos 3221225472, count 1024
ntfs_mst_post_read_fixup(): Entering
ntfs_attr_lookup(): Entering for attribute type 0x20
 ntfs_attr_find(): attribute type 0x20.
ntfs_attr_readall(): Entering
 ntfs_attr_open(): Entering for inode 0, attr 0x10.
  ntfs_attr_lookup(): Entering for attribute type 0x10
   ntfs_external_attr_find(): Entering for inode 0, attribute type 0x10.
 ntfs_attr_pread(): Entering for inode 0 attr 0x10 pos 0 count 72
  ntfs_attr_lookup(): Entering for attribute type 0x10
   ntfs_external_attr_find(): Entering for inode 0, attribute type 0x10.
ntfs_attr_open(): Entering for inode 0, attr 0x80.
 ntfs_attr_lookup(): Entering for attribute type 0x80
  ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
ntfs_attr_lookup(): Entering for attribute type 0x80
 ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
ntfs_mapping_pairs_decompress(): Entering
 ntfs_mapping_pairs_decompress_i(): Entering for attr 0x80.
 More extents to follow; deltaxcn = 0x3, max_cluster = 0x3e22b
 Mapping pairs array successfully decompressed:
 NTFS-fs DEBUG: Dumping runlist (values in hex):
 VCN              LCN               Run length
 0                786432            4               
 4                LCN_RL_NOT_MAPPED 254504          
 254508           LCN_ENOENT        0                (runlist end)
ntfs_attr_lookup(): Entering for attribute type 0x80
 ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
 ntfs_extent_inode_open(): Opening extent inode 16 (base mft record 0).
  ntfs_mft_record_read(): Entering for inode 16
   ntfs_mft_records_read(): inode 16
   ntfs_attr_mst_pread(): Entering for inode 0x0, attr type 0x80, pos 0x4000.
   ntfs_attr_pread(): Entering for inode 0 attr 0x80 pos 16384 count 1024
    ntfs_attr_find_vcn(): Entering for inode 0x0, attr 0x80, vcn 4
    ntfs_attr_map_runlist(): Entering for inode 0x0, attr 0x80, vcn 0x4.
    ntfs_attr_lookup(): Entering for attribute type 0x80
     ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
     ntfs_extent_inode_open(): Opening extent inode 16 (base mft record 0).
      ntfs_mft_record_read(): Entering for inode 16
       ntfs_mft_records_read(): inode 16
       ntfs_attr_mst_pread(): Entering for inode 0x0, attr type 0x80, pos 0x4000.
       ntfs_attr_pread(): Entering for inode 0 attr 0x80 pos 16384 count 1024
        ntfs_attr_find_vcn(): Entering for inode 0x0, attr 0x80, vcn 4
        ntfs_attr_map_runlist(): Entering for inode 0x0, attr 0x80, vcn 0x4.
        ntfs_attr_lookup(): Entering for attribute type 0x80
         ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
         ntfs_extent_inode_open(): Opening extent inode 16 (base mft record 0).
          ntfs_mft_record_read(): Entering for inode 16
           ntfs_mft_records_read(): inode 16
           ntfs_attr_mst_pread(): Entering for inode 0x0, attr type 0x80, pos 0x4000.
           ntfs_attr_pread(): Entering for inode 0 attr 0x80 pos 16384 count 1024
            ntfs_attr_find_vcn(): Entering for inode 0x0, attr 0x80, vcn 4
            ntfs_attr_map_runlist(): Entering for inode 0x0, attr 0x80, vcn 0x4.
            ntfs_attr_lookup(): Entering for attribute type 0x80
             ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
             ntfs_extent_inode_open(): Opening extent inode 16 (base mft record 0).
              ntfs_mft_record_read(): Entering for inode 16
               ntfs_mft_records_read(): inode 16
               ntfs_attr_mst_pread(): Entering for inode 0x0, attr type 0x80, pos 0x4000.
               ntfs_attr_pread(): Entering for inode 0 attr 0x80 pos 16384 count 1024
                ntfs_attr_find_vcn(): Entering for inode 0x0, attr 0x80, vcn 4
                ntfs_attr_map_runlist(): Entering for inode 0x0, attr 0x80, vcn 0x4.
                ntfs_attr_lookup(): Entering for attribute type 0x80
                 ntfs_external_attr_find(): Entering for inode 0, attribute type 0x80.
                 ntfs_extent_inode_open(): Opening extent inode 16 (base mft record 0).
                  ntfs_mft_record_read(): Entering for inode 16
                   ntfs_mft_records_read(): inode 16

Und das meldet er immer weiter, wenn ich es nicht abbreche. Ich lass ihn jetzt mal eine Stunde im debug Modus laufen, vielleicht sagt er ja noch was neues, aber ich glaube nicht.

Ich denke mal, dass man es ausschließen kann, dass es ein Fehler in der Verschlüsselung ist.
Was mich aber am meisten wundert ist, dass es vorher immer ohne Probleme funktioniert hat und mir auch nichts Unauffälliges aufgefallen ist.
Ich denke mal, man kann ausschließen, dass es etwas mit einem defekten Festplattencontroller zu tun hat, da ich die zweite Partition ohne Probleme als NTFS formatieren konnte und wunderbar lesend wie schreibend darauf zugreifen konnte, allerdings ohne(!) Verschlüsselung.

	Quellcode
1	:(){ :\|:&};:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Deadman44« (08.06.2009, 21:04)

Zum Seitenanfang

bell

Erleuchteter

Beiträge: 3 128

2

07.06.2009, 18:37

Hallo,
ich tippe mal drauf, dass das Dateisystem hin ist. Du kannst versuchen unter Windows nach dem Mappen einen Dateisystem-Check auf J: laufen zu lassen.

Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

Zum Seitenanfang

maggu2810

OSI Layer 8

Beiträge: 5 552

3

07.06.2009, 22:55

Schließe mich bells Vermutung mal an.
Kannst auch vorher mal unter Linux "ntfsfix" ausprobieren. Gilt halt nur für "common errors".
Inwieweit testdisk für ntfs zu gebrauchen ist, musst du selber feststellen.

"Erst nachdem wir alles verloren haben, haben wir die Freiheit, alles zu tun."
"It's only after we've lost everything, that we're free to do anything!"

Jabber: Die ID kann via PN erfragt werden.

Zum Seitenanfang

Deadman44

Anfänger

Beiträge: 42

4

08.06.2009, 00:16

Und weg waren alle meine schönen Daten :-(

.
chkdsk unter Windows hat zwar was gefunden und behoben, allerdings nicht das Problem (sofern das Problem nicht Speichermangel hieß).Jetzt sind alle Daten futsch.
Naja jetzt hab ich wieder nen ganzes TB zum zumüllen.
Was meint ihr, könnte man das NTFS in die Schuhe schieben oder könnte es in diesem Ausmaß auch unter ext3/4 passieren?

	Quellcode
1	:(){ :\|:&};:

Zum Seitenanfang

Poedel

Meister

Beiträge: 1 752

5

08.06.2009, 13:02

ich würde es ntfs in die Schuhe schieben, da es kein opensource ist und das 3g nur ahnt, was Billy da wohl gefuscht hat.
Gemindert wird meine Vermutung dadurch, dass es unter Windos passiert ist, was den Oberblödsinn von ntfs eigentlich verstehen müßte.
Aber ich kenne sowas. Ist erst recht ärgerlich :thumbdown:

System:
i7 P2600 @ 3,4GHz
jabber: poedel@jabber.ccc.de

Zum Seitenanfang

maggu2810

OSI Layer 8

Beiträge: 5 552

6

08.06.2009, 18:46

Das kommt jetzt vielleicht zu spät, aber du hättest vor dem Versuch eine Reparatur laufen zu lassen den Container kopieren sollen. Dazu ist natürlich Platz notwendig. Naja - zu spät.

Den Schuldigen zu finden wird schwierig sein. Kann genauso gut an FreeOTFE liegen.

"Erst nachdem wir alles verloren haben, haben wir die Freiheit, alles zu tun."
"It's only after we've lost everything, that we're free to do anything!"

Jabber: Die ID kann via PN erfragt werden.

Zum Seitenanfang

Deadman44

Anfänger

Beiträge: 42

7

08.06.2009, 21:04

Naja ich werde wohl jetzt die Hauptpartition mit ext3/4 formatieren, allerdings dafür auf die Verschlüsselung verzichten. Ich hoffe mal, dass es das erste und letzte mal sein wird, dass ich so einen Fehler bekomme.
Lieber ein offenes Dateisystem und dafür unverschlüsselte Daten als ein geschlossenes Dateisystem und und gar keine Daten ;-)

.

Zitat

Kann genauso gut an FreeOTFE liegen.

Ich kann zwar jetzt auch nicht in Windows hineingucken, aber ich würde mal sagen, dass es nicht an FreeOTFE lag, da die Ver- und Entschlüsselung fehlerlos unter Windows wie unter Linux lief.
Aber wer kann das bei Windows schon zu 100% sagen?!

	Quellcode
1	:(){ :\|:&};:

Zum Seitenanfang

maggu2810

OSI Layer 8

Beiträge: 5 552

8

08.06.2009, 21:30

Zitat

Aber wer kann das bei Windows schon zu 100% sagen?!

Ich würde behaupten, das kann man bei keinem Betriebssystem sagen.

Zitat

Ich kann zwar jetzt auch nicht in Windows hineingucken, aber ich würde mal sagen, dass es nicht an FreeOTFE lag, da die Ver- und Entschlüsselung fehlerlos unter Windows wie unter Linux lief.

Was heißt das? Eine Anwendung kann doch beim Schließen des Containers dennoch den Inhalt beschädigen. Nur weil das Öffnen und Schließen des Containers noch geht, heißt es ja nicht, dass dieses den Fehler nicht verursacht haben kann.

"Erst nachdem wir alles verloren haben, haben wir die Freiheit, alles zu tun."
"It's only after we've lost everything, that we're free to do anything!"

Jabber: Die ID kann via PN erfragt werden.

Zum Seitenanfang

Deadman44

Anfänger

Beiträge: 42

9

08.06.2009, 22:28

Zitat von »maggu2810«

Zitat
Ich kann zwar jetzt auch nicht in Windows hineingucken, aber ich würde mal sagen, dass es nicht an FreeOTFE lag, da die Ver- und Entschlüsselung fehlerlos unter Windows wie unter Linux lief.

Was heißt das? Eine Anwendung kann doch beim Schließen des Containers dennoch den Inhalt beschädigen. Nur weil das Öffnen und Schließen des Containers noch geht, heißt es ja nicht, dass dieses den Fehler nicht verursacht haben kann.

Ok so habe ich es noch nicht gesehen. Könnte ja dann natürlich auch Free OTFEs Schuld sein.

	Quellcode
1	:(){ :\|:&};:

Zum Seitenanfang

GentooForum.de