HFS+ auf externer Festplatte geht ständig kaputt und kann nicht repariert werden

nicht unbedingt mit kopiert, das könnte ein verkümmerter zweig sein oder die datei ist nicht mit kopiert worden.
gäbe ja einen fehler beim kopieren.
 
Aber warum taucht genau dasselbe Problem dann immer wieder auf? Ich kopiere die Daten gerade zum dritten Mal zurück. Fehler beim Kopieren hat es nie gegeben.
 
check doch mal die platte, wo du die daten zwischengelagert hast.
gibt es da den gleichen fehler?
 
  • Gefällt mir
Reaktionen: IceSheep
Oh, das war eine gute Idee. Es tritt bei dem Volume tatsächlich derselbe Fehler auf. Jetzt heißt es auch, dass das Volume repariert werden muss, was aber fehlschlägt. Also genau dasselbe Verhalten. Dann haben wir Hardware-Probleme schon mal ausgeschlossen :)

Wie finde ich denn jetzt heraus, wo sich dieser "ungültige Name" befindet?
 
du könntest mal im terminal
fsck_hfs -d /Volume/Platte
proberen, dann sollte der mehr information ausgeben, wenn der nicht reparieren kann.
 
  • Gefällt mir
Reaktionen: IceSheep
Also ohne 100 $ keine Chance?

Mir würde jetzt spontan noch einfallen, die Daten auf ein ext3 oder xfs Volume zu kopieren und dann zurück auf HFS+. Dann wäre die Chance doch relativ gering, einen Dateisystem-Fehler mit zu übernehmen. Oder was meint ihr?
 
nimm das terminal ;)
oder kopier die daten in stücken, damit du es einkreisen kannst.
 
  • Gefällt mir
Reaktionen: IceSheep
oneOeight schrieb:
du könntest mal im terminal
fsck_hfs -d /Volume/Platte
proberen, dann sollte der mehr information ausgeben, wenn der nicht reparieren kann.
Zum Vergrößern anklicken....

Code: 
$ fsck_hfs -d /Volumes/mb_auslagerung
/Volumes/mb_auslagerung is not a character device
CONTINUE? [yn] y

** /Volumes/mb_auslagerung (NO WRITE)
Can't get device block size

Klappt nicht. Woran mag das liegen?
 
mein fehler du musst die device angeben.
tipp mal vorher mount und guck mal dann vorne bei /dev/disk steht.
dann musst du halt die platte auswerfen und entsprechen
fsck_hfs -d /dev/diskXsY
machen (X und Y durch die richtige zahl ersetzen).
 
Ich hab's grad selbst bemerkt :)

Ich glaube, wir nähern uns dem Problem.

Code: 
$ fsck_hfs -d /dev/disk2s2
** /dev/rdisk2s2
        Using cacheBlockSize=32K cacheTotalBlock=16384 cacheSize=524288K.
   Executing fsck_hfs (version diskdev_cmds-491.2~2).
        Journal replayed successfully or journal was empty
** Checking Journaled HFS Plus volume.
** Checking extents overflow file.
** Checking catalog file.
   Illegal name
        illegal name is 0x32 00 31 00  [I](von mir gekürzt)[/I]
        replacement name is 0x32 00 31 00  [I](von mir gekürzt)[/I]
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
   Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000
                  CBTStat = 0x0000 CatStat = 0x00008000
** Repairing volume.
        replacement name already exists 
        duplicate name is 0x32 00 31 00 ... [I](von mir gekürzt)[/I] 
        FixIllegalNames - repair failed for type 0x23B 571 
** The volume mb_auslagerung could not be repaired.
        volume type is pure HFS+ 
        primary MDB is at block 0 0x00 
        alternate MDB is at block 0 0x00 
        primary VHB is at block 2 0x02 
        alternate VHB is at block 1953124998 0x746a5286 
        sector size = 512 0x200 
        VolumeObject flags = 0x07 
        total sectors for volume = 1953125000 0x746a5288 
        total sectors for embedded volume = 0 0x00

Die Daten stammen von Linux-Dateisystemen. Jetzt habe ich folgende Vermutung: Die Linux-Dateisysteme unterscheiden alle zwischen Groß- und Kleinschreibung (sinnvollerweise, wie ich finde). HFS+ tut das in der Standardeinstellung (mit der ich formatiert habe) nicht.

Versucht der Reparatur-Vorgang jetzt möglicherweise, Dateien umzubenennen, die es in abweichender Groß- und Kleinschreibung dann schon gibt? Dann ließe sich das Problem ja eventuell lösen, indem ich mit "Mac OS Extended (Groß-/Kleinschreibung und Journaled) formatiere.

Meinungen dazu?
 
bist du sicher, dass es am groß/klein liegt?
der filename beginnt doch mit 21, ist also eine zahl...
lass die datei doch aus oder benenn die so um...
 
Code: 
217 - Δέσποινα Βανδή - Opa Opa.mp3
217 - Δε̍σποινα Βανδη̍ - Opa Opa.mp3

Voilà. Also doch nicht die Groß- und Kleinschreibung. Dafür aber fiese UTF-8-Zeichen.

Da OS X jetzt von dem Fehler weiß, lässt sich die Platte nur noch read-only mounten. Gibt es einen Weg, Schreibzugriff zu erzwingen?
 
mount -f /dev/diskXsY /Volumes/verzeichnis
 
Das hatte ich mir schon gedacht, aber das haut nicht hin:

Code: 
sudo mount -f /dev/disk1s2 /mnt/mb_auslagerung
/dev/disk1s2 on /mnt/mb_auslagerung: Incorrect super block.

bzw.

Code: 
sudo mount -t hfs -f /dev/disk1s2 /mnt/mb_auslagerung
mount_hfs: -o force: option not supported
 
probier mal -w statt -f ...

aber du wolltest du eh rüber kopieren oder hast du schon?
dann kopier mal alle files bis auf das eine.
 
Code: 
sudo mount -t hfs -w /dev/disk1s2 /mnt/mb_auslagerung
mount_hfs: Invalid argument

Ich fürchte, das geht nicht. Laut man hfs_mount gibt's auch nichts anderes, was man noch probieren könnte.
 
probier mal das -w vor dem -t hfs ...
ansonsten gibt es noch
mount -u -w /dev/disk1s2
wenn die platte so schon gemountet wurde...
 
Ja, ich muss sowieso alle zurückkopieren und kann die kaputte dann ja auch von dem neuen Volume löschen (oder wie du vorschlägst, gar nicht erst mitkopieren).

Es wäre aber ganz nützlich, wenn ich das Backup-Volume dann nicht auch noch mal neu formatieren müsste. Wenn ich die Original-Platte wiederhergestellt habe, probiere ich mal, die Datei unter Linux zu löschen.
 
reparier vielleicht noch mal mit dem festplattendienstprogramm, vielleicht markiert der dann die volume wieder als schreibbar...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten