Gönner-Abo

Ab CHF 5.– im Monat

👉🏼 Wir benötigen deine Unterstützung! Unterstütze macprime mit einem freiwilligen Gönner-Abo und mache die Zukunft unseres unabhängigen Apple-Mediums aus der Schweiz mit möglich.

macprime unterstützen

 macprime Forum

Dateikopieren von FAT32 auf HFS: eine Odysee. Jemand eine Idee?

 

VonAntwort von Nick Klaas

Hallo zusammen,

bisher habe ich meine Daten alle auf einem Windows-Rechner gehabt, jetzt möchte ich gern komplett auf mein MacBookPro umziehen. Aber das ist nicht so einfach. Die Fakten: rund 40GB Daten sollen auf den Mac, insgesamt rund 150.000 Dateien. Als Medium nutze ich eine USB-Platte 500GB Fat32 (weil das beide Systeme noch am ehesten verstehen, dachte ich).

  • Kopieren vom Windowssystem auf die Platte: Problemlos.
  • Kopieren von der Platte auf den Mac: hürdenreich. Die Einzelschritte:
  • kopieren mit dem Finder: nach 8GB kommt die Meldung, eine Datei unterscheide sich durch eine auf dem Ziellaufwerk nur durch die Gross-Kleinschreibung (völliger Blödsinn, ich habe in ein leeres Verzeichnis kopiert)
  • kopieren mit muCommander: scheitert direkt am Anfang: er kann jede zweite Datei nicht lesen
  • kopieren mit ForkLift: scheitert auch am Anfang: Lesefehler bei derselben Datei, dann Abbruch
  • kopieren mit CarbonCopy: fängt gar nicht erst an, weil FAT32 nicht unterstützt wird

Festplatten-Dienstprogramm überprüft USB Fat32-Platte und Mac-HFS-Platte: keine Fehler gefunden.

Ich sitze jetzt geschätzte 13 Stunden an dieser Aufgabe und bin langsam mit meinem Latein am Ende. Hat jemand eine Idee dazu? Ich meine: Das ist doch eine nicht ganz verrückte Sache, oder, viele Dateien vom PC-System auf ein Mac-System zu spielen.

Ich habe mir auch MacDrive vor einiger Zeit gekauft, so dass man das ganze mal mit HFS-Basis ausprobieren könnte. Nur ehrlich: Ich schrecke vor den Stunden Arbeit und dann hingen meine Daten der letzten zehn Jahre eben am MacDrive-Programmierer..

Hilfe würde mich sehr freuen!! Bis dann, Nick

Unsere Sponsoren

Profilfoto von pse

pse

Naja, mit dem Kopieren von FAT nach HFS hatte ich auch schon so meine Erlebnisse. Gerade im Zusammenspiel mit USB kommt es da immer wieder mal zu Problemen (oft vermutlich durch irgendwelche Timing-Issues bedingt, auch Umlaute in Filenamen kommen nicht immer heil über die Leitung) die sich dann in mehr oder weniger hilfreichen Fehlermeldungen äussern. Du könntest versuchen, jedes Top-Verzeichnis einzeln zu kopieren (und das nächste erst zu kopieren wenn das erste fertig ist), aber bei vielen Dateien im Verzeichnis hilft das dann auch nicht unbedingt.

Terminal to the rescue!

cd /Volumes/FATDisk
for d in *; do echo START $d; cp -R $d /Volumes/HFSDisk; echo DONE $d; done

Für FATDisk und HFSDisk musst Du natürlich die entsprechenden Volume-Namen einsetzen. Falls Quelle/Ziel nicht im Rootverzeichnis des jeweiligen Laufwerks sind, kannst Du den Pfad entsprechend ergänzen. Wenn Du sicherstellen willst, dass wirklich keine Files wegen der Gross/Klein-Geschichte überschrieben werden, lautet der Kopier-Befehl “cp -iR” (dann wirst Du vor dem Überschreiben gefragt) oder Du formatierst die Zielplatte neu und richtest ein HFS mit Gross/Klein-Unterstützung ein.

 

Nick Klaas

Hallo pse, vielen Dank für die gute Idee. Nach wie vor hapert es (wäre ja zu schön gewesen) und ich bin sehr interessiert an Euren Ideen:

  1. evtl. gibt es Probleme mit Verzeichnisnamen, die Leerzeichen enthalten Der Verzeichnisname “CD Zusammenstellungen” führt zu START CD Zusammenstellungen cp: CD: No such file or directory cp: Zusammenstellungen: No such file or directory DONE CD Zusammenstellungen

Ähnliches Problem: Der Verzeichnisname “-war mal auf mac” führt zu START -war mal auf mac cp: illegal option – w usage: cp [-R [-H | -L | -P]] [-fi | -n] [-pvX] source_file target_file cp [-R [-H | -L | -P]] [-fi | -n] [-pvX] source_file … target_directory DONE -war mal auf mac

  1. und es scheint Rechteprobleme zu geben: Das Kopieren eines Films führt zu cp: DVDs/._sandanimation.wmv: could not copy extended attributes to /Users/temp1/Documents/neu-von-pc/DVDs/._sandanimation.wmv: Operation not permitted Meint der archive, hidden, usw.? Das nutze ich bei den Daten sowieso grade nicht.

Habt ihr noch eine Idee? Danke!

(Bearbeitet am 02. April 2009 um 14:41 Uhr von Nick Klaas)

Profilfoto von pse

pse

Shit, mein Fehler, sorry.

cd /Volumes/FATDisk
for d in *; do echo "START $d"; cp -R ./"$d" /Volumes/HFSDisk; echo "DONE $d"; done

Den Fehler mit den extended attributes kann ich mir nicht so recht erklären, sowas unterstützt FAT32 doch gar nicht?! Und hat es auf dem FAT32-Volume wirklich eine Datei die mit einem Punkt beginnt (._sandanimation.wmv)? Strange… Aber eigentlich (die Man-page ist da ein bisschen unklar) sollte cp -R bei solchen Fehlern nicht abbrechen, also musst Du allenfalls diese (hoffentlich wenige) Files anschliessend von Hand kopieren.

 

Nick Klaas

Vielen Dank, pse, gute Folge des Rumprobierens: bei der Gelegenheit lerne ich meine ersten Schritte Terminal. Ist ja gar nicht so anders als DOS, denke ich, zumindest noch ;)

Werde die Ideen von Dir gleich mal ausprobieren. Habe in der Zwischenzeit noch die Trial von Paragons NTFS for Mac runtergeladen, das soll FAT-Konvertierungsprozesse erleichtern, der Finder-Prozess läuft grade. Erstaunlich: Braucht jetzt nur 25 Minuten statt wie vorhin 2 Stunden.

Bis dahin, Danke.

Profilfoto von pse

pse

Naja, die Leerzeichen-Problematik erwischt mich immer wieder weil ich aus lauter Unix-Gewohnheit eigentlich nie Filenamen mit Leerzeichen drin (oder einem - am Anfang) mache. Aber die zweite Version sollte mit allem ausser ” und Zeilenumbruch klarkommen (und das bringst Du mit normalen Mitteln beides nicht in einen FAT32-kompatiblen Filenamen).

Um noch ein bisschen Ausbildung zu betreiben: Unter Unix kriegen die Kommandos die ganzen Parameter einzeln als Strings überreicht, die Shell erkennt Leerzeichen als Trennung zwischen zwei Parametern. Und da $xyz aufgelöst wird, bevor die Shell die Parameter bestimmt, werden dann eben mehrere Parameter draus, mit Einpacken in “” zeigst Du der Shell dass das zusammengehört. Analog der Trick mit dem ./ vor der Quelle: Parameter mit - am Anfang sind Optionen (analog zu / unter DOS), wenn nun ein Filename so anfängt, wird der als Option interpretiert. ./ bezeichnet das aktuelle Directory was im konkreten Fall quasi eine “No Operation” darstellt (d.h. keinen Einfluss auf den Pfad zum File hat aber cp ein bisschen “überlistet”).

Geschwindigkeitszuwachs überrascht mich nicht, der Finder ist notorisch langsam beim Kopieren oder Löschen.

 

Nick Klaas

Vielen Dank für die Infos. Dass aus Leerzeichen Parametertrenner werden, kommt mir bekannt vor. Und das ./ ist äußerst clever. Ich werde jetzt zur Tat schreiten: Finder ist grade wieder mit “vermutlich ein Aliastyp, der vom Zielsystem nicht unterstützt wird” nach 14 GB in die Knie gegangen.. Kennst Du zufällig auch eine Softwarealternative zu Finder/Linux? Auf Windows gibt´s da sehr clevere Kontextmenü-Kopiererweiterungen, die mit solchen Sachen dann immer klarkommen (und vor allem nicht mittendrin alles abbrechen). So, aber jetzt erstmal Terminal. Es ist eine Freude.

 

Nick Klaas

Mmh. Also das funktioniert auch nicht. Nach zwei Minuten hagelt es Fehlermeldungen. Der Befehl, noch etwas veränderte Parameter: for d in *; do echo “START $d”; cp -inpR ./”$d” /Users/temp1/Documents/neu-von-pc; echo “DONE $d”; done

gute Nachricht: Das Problem mit “-war mal auf Mac” ist gelöst. Leerzeichen auch OK. schlechte Nachricht: direkt ein dutzend Fehlermeldungen: * could not copy extended attributes to … Operation not permitted * anscheinend auch noch Probs mit Umlauten: cp: ./Listen/Mitgliedschaften/Übersicht Mitgliedschaften.mm: No such file or directory cp: ./Listen/Podcasts. RSS/Podcasts köln.opml: No such file or directory

Noch Ideen? Danke für die Geduld ;)

Profilfoto von pse

pse 

-n: do not overwrite an existing file.  (The -n option overrides any previous -f or -i options.)

Entweder -n oder -i, entscheide Dich :-)

Die Umlaute überraschen mich nicht wirklich, leider :-( Du kannst noch folgendes probieren:

cd /Volumes/FATDisk
for d in *; do tar -cjpf - $d | (cd /Volumes/HFSDisk; tar -xvjpof -); done

(und ja, das ist jeweils ein einsames - ohne sonstwas). Allerdings könnten da die Umlaute auch Probleme bereiten.

Wenn das auch nicht klappt (schau mal ins Zielverzeichnis was allenfalls da unterdessen schon angekommen ist) -> Umlaute von Hand umbenennen ist wohl am einfachsten. Ginge zwar auch mit einem Shellscript, aber ich habe keine FAT32-Disk hier und ungetestet will ich das nicht auf die Welt loslassen.

 

Nick Klaas

Hallo pse,

danke für deine Idee. Ich habe es jetzt mal mit einer ganz anderen Lösung versucht, die sinnvoll sein könnte: Habe meine externe USB auf NTFS formatiert, da die Daten draufgespielt und hoffe jetzt, dass der Mac sie fraglos annimmt, weil NTFS sollte er ja lesen können. Sonst gibt es ja auch dieses MacFuse und NTFS for Mac, das wollte ich mir auch mal anschauen.

Vielen Dank für die Hilfe auf jeden Fall! Schönen Gruß!

Anmelden um neue Antworten zu verfassen

Allegra Leser! Nur angemeldete Nutzer können bei diesem Beitrag Antworten hinterlassen. Jetzt kostenlos registrieren oder mit bestehendem Benutzerprofil anmelden.