Windows zu Mac: Umzug, aber die Kisten passen nicht durch die Tür - Fehler -43

Nein. Intern verwendet macOS den POSIX-Schrägstrich. Der Doppelpunkt wird aus Kompatibilitätsgründen noch akzeptiert, hat aber keine relevante Bedeutung mehr.
 
  • Gefällt mir
Reaktionen: Schiffversenker
Der absolute Großteil ist auf jeden Fall nun auf dem Mac. Herzlichen Dank dafür! Nur manche Dateinamen hat es zerschossen. Zum Beispiel wurde "_Themen.docx" zu "~$Themen.docx"

Wobei ich gerade feststelle: Es existierte nur eine Datei namens _Themen.docx. Die ist auch sauber rüberkopiert. Und die zweite, mit kaputtem Namen, ist hinzugekommen und lässt sich nicht öffnen.
Dateien mit dem Präfix ~ werden auf Windows Rechner nicht angezeigt und sind meist Temp- oder Lockdateien. Beim Windowsrechner musst du, um diese anzeigen zu lassen, dies in den Einstellungen vom Explorer erst einschalten. Andersherum tauchen auf Windowsrechner beim anschließen einer Platte mit Appledaten immer Dateien mit einem Punkt als ersten Charakter auf.

Was sind denn das für Dateien die du nicht kopiert bekommst? Gib mal ein paar Vorbilder der kompletten Dateinamen.

Ich hatte auch mal ein interessantes Phänomen. Ich hatte mal eine externe Festplatte, ich weiß jetzt nicht ob es FAT32 oder ExFat ist, aber ich denke FAT32. Hierrauf befinden sich zwei Ordner: "Software für Mac" und "Software für Windows". Und auf einigen Rechnern tauschte immer nur einer dieser beiden Ordner auf.
 
Ach und zum kopieren kannst du besser FreeFileSync nehmen. Der geht bei einem Fehler einfach weiter und man bekommt eine Übersicht mit den Dateien die nicht kopiert werden konten.

Ich war gestern auch damit beschäftigt eine Festplatte aus einem iMac G4 auszulesen. Und da blieb der Finder auch irgendwann einfach stehen mit der Meldung, er könnte eine Datei nicht kopieren. Da habe ich es mit FFS durchgeführt. Bei der ersten Fehler Meldung einfach "Ignore all" anklicken und er rattert durch. Am ende blieb eine handvoll Dateien die nicht kopiert werden konnten. (die Platte hat aber auch ein Hau weg, eventuell muss ich da noch mal mit DiskWarrior dran)
 
  • Gefällt mir
Reaktionen: dg2rbf
Es bleibt aber relevant für die Benutzbarkeit in Dateinamen.

Stimmt, daher kannst du auf der Kommandozeile Dateien namens „:“ anlegen, nicht jedoch Dateien namens „/“. (Dass der Finder diese Dateinamen in der Anzeige umwandelt, belegt Weiteres.)
 
Ich werfe dann mal ein paar andere Methoden in den Raum:

Auf die "altmodische" Weise:
- Auf der Windows-Kiste den gewünschten Ordner im Netzwerk freigeben
- Auf dem Mac zu der Windows-Kiste und dem freigegebenen Ordner verbinden
- Daten umkopieren - kann etwas länger dauern
Der Vorteil besteht dann darin, dass sich die beteiligten Kisten und Protokolle selbst um eventuelle Namens- und Attribut-Konflikte kümmern und sowas auflösen.

Oder:
- die Windows-Kiste und die Freigaben als "NAS" weiterlaufen lassen und die Sachen erst gar nicht erst umkopieren

Oder "modern":
- die Windows-Ordner an Microsoft's OneDrive-Cloud anknoten - viele haben da 1TB für lau - der anfängliche Upload kann etwas dauern.
- OneDrive auf dem Mac installieren und auf beiden Systemen mit den gleichen Daten arbeiten.
 
  • Gefällt mir
Reaktionen: Schiffversenker und dg2rbf
So, Terminal ist nun fertig. Ich weiß ehrlich gesagt nicht, wo ich nun die Fehlermeldungen finde?
Das Terminal sollte dir im gleichen Fenster für jede nicht kopierbare Datei eine Fehlermeldung ausgegeben haben, das kann zB so ausschauen:

Code:
rsync: opendir "Pictures" failed: Permission denied (13)
rsync: opendir "Desktop" failed: Permission denied (13)
rsync: opendir "Library" failed: Permission denied (13)

Daraus geht eben auch ein bisschen was zur Fehlerursache hervor, im Beispiel zeigt es ein Berechtigungsproblem an.

Und die zweite, mit kaputtem Namen, ist hinzugekommen und lässt sich nicht öffnen.
Die war wie schon gesagt wurde bereits vorher vorhanden, unter Windows aber ausgeblendet. Da ist irgendwann mal Word abgestürzt während du das Dokument offen hattest und diese Datei blieb zurück. Die hat keinen kaputten Namen, die wurde von Word damals absichtlich so angelegt. Die kann man auch nicht öffnen. Das ist einfach ein Platzhalter der anzeigt, dass das Dokument gerade in Word offen ist. Du kannst die Datei löschen. Aber das wurde schon richtig kopiert, da handelt es sich nicht um einen Fehler.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich habe nochmal in den Terminal-Text geschaut. Die Fehlermeldungen sind folgender Art: "file has vanished: XXXXX". Ich habe fast den Eindruck, dass es einfach ein Problem mit Umlauten ist. Was seltsam ist, weil auch viele Dateien mit Umlauten im Namen problemlos rüberkopiert wurden. Aber die Umlaute im Namen scheinen alle Dateien mit Fehlermeldung gemeinsam zu haben. Einige Beispiele zu den Dateien, wie sie in der Terminal-Fehlermeldung gelistet werden:

"#210bersicht mit Bildunterschriften.pdf" statt "Übersicht (...)"
"Immatrikulationsbesta?\#210tigung.pdf" statt "Immatrikulationsbestätigung"
"Auch_mal_Gemu?\#210se.jpg" statt "(...) Gemüse"
"Landra?\#210tin zum 210618_.pdf" statt "Landrätin (...)"
 
Kannst du mal den muCommander zum Kopieren probieren?
 
Ich habe fast den Eindruck, dass es einfach ein Problem mit Umlauten ist. Was seltsam ist, weil auch viele Dateien mit Umlauten im Namen problemlos rüberkopiert wurden.
»Umlaut« ist nicht gleich »Umlaut«:
<ä> und <> sehen zwar gleich aus, nur ist ersteres Zeichen U+00E4 (LATIN SMALL LETTER A WITH DIAERESIS) …
und zweites ist ein U+0061 (LATIN SMALL LETTER A) plus ein U+0308 (COMBINING DIAERESIS).

Wenn es im Unicode ein »fertiges« Zeichen gibt, soll es bevorzugt verwendet werden; die Version mit der Kombinierung soll die (heute ältere) Ausnahme sein. Nicht jedes Dateisystem und nicht jede Anwendung kommt mit zusammengesetzten Zeichen zurande. Siehe die hie und da mal auf Webseiten oder in PDFs in Einzelzeichen aufgelösten oder verschoben dargestellten Zeichen (hier als <> simuliert).

"Immatrikulationsbesta?\#210tigung.pdf" statt "Immatrikulationsbestätigung"
"Auch_mal_Gemu?\#210se.jpg" statt "(...) Gemüse"
Da wird dann das <ä> oder das <ü> vom Dateisystem maskiert, um es zu erhalten.
 
  • Gefällt mir
Reaktionen: OmarDLittle, dg2rbf und Macschrauber
Die richtige Zeichenkodierung im Terminal wirkt auch wunder...
 
  • Gefällt mir
Reaktionen: dg2rbf
Wenn das nur wenige einzelne Dateien sind, kopier die einfach manuell anderweitig. Jetzt hast du immerhin eine vollständige Liste aller nicht kopierten Dateien.

Da hat der Mac wohl tatsächlich Probleme mit der Kodierung, rsync könnte es eigentlich selbst lösen und dann richtig kopieren, allerdings ist das rsync das MacOS mitbringt ein bisschen eingeschränkt und kann das nicht, zumindest unterstützt mein rsync auf Monterey kein --iconv. Es geht mit dem neueren rsync via homebrew, aber dann wirds ein wenig aufwändiger. Daher der Vorschlag es für die wenigen einzelnen Dateien zu machen.

Bzw. kannst du die Dateien auch umbenennen, evtl. noch unter Windows wenn der Finder es nicht zulässt.
 
Liebe Leute, es ist geschafft! Das waren nur rund 20 Dateien, die nicht rüberkopiert werden konnten und die das ganze Problem verursachten. Dank eurer Tipps konnte ich die ausfindig machen. Die habe ich auf Windows nun händisch umbenannt bzw. teilweise gelöscht, wenn sie unnötig waren. Und nun konnte ich meine ganze Datenmenge problemlos auf den Mac ziehen. Ich danke euch für eure Hilfe und alles Gute fürs kommende Jahr! LG
 
  • Gefällt mir
Reaktionen: stpf und Mad Mac
Mei Favorit: FreeFileSync, gibt es kostenlos für Windows und macOS.
Es stoppt nicht wenn ein Fehler vorkommt, sonder protokolliert den Vorfall und macht weiter.
So, wie eigentlich alle erwachsene Betriebsysteme es machen sollten.
 
  • Gefällt mir
Reaktionen: gerli09
Zurück
Oben Unten