Problem beim Kopieren von gleichen Dateien mit Umlauten...

Holundervogel

Neues Mitglied
Thread Starter
Dabei seit
25.04.2020
Beiträge
14
Reaktionspunkte
0
Hallo allerseits,
seit einer Woche bin ich Besitzer eines MacBook und bin derzeit dabei, meine Daten vom alten Windows-Rechner auf das Macbook zu übertragen.
Hierbei bin ich auf folgendes Phänomen gestoßen:

Wenn ich Dateien kopieren will, deren Name fast gleich ist und sich nur durch die Nutzung eines Umlautes unterscheidet wird das Kopieren mit der Meldung, daß die Datei schon vorhanden wäre, abgebrochen.
Beispiel:
Ich will die Dateien 'wetten dass.txt' und 'wetten daß.txt' kopieren.
Beide Dateien befinden sich in einem Verzeichnis auf meiner externen Platte, die ich zum Kopieren nutze und sollen in einen Ordner auf dem MacBook kopiert werden.
Wie oben schon geschrieben wird dieser Kopiervorgang abgebrochen.
Für mich sieht es so aus, als ob MacOS ein 'ß' als 'ss' interpretiert.
Kann das jemand bestätigen und wenn ja, gibt es eine Möglichkeit, dieses Verhalten abzuschalten?

Vielen Dank im voraus für jegliche Hilfe.
 
also ich kann hier auf HFS+ nicht reproduzieren.
was für ein dateisystem hat denn die platte von der du kopierst?
normal sind doppel s und ß unterschiedliche zeichen in allen zeichensätzen.

edit:
hab es jetzt noch mal auf APFS probiert, da ist es tatsächlich so.
aber normal fragt dich der finder dann, ob du beide behalten willst.
oder wenn beide zusammen kopiert werden, macht der automatisch eine 2 dahinter.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Hmmmm ASCII-Code-Tabbellen sind schon manchmal seltsam.

So wird schon mal aus einem ß (225) ein á (0225) oder andere seltsame Effekte könne auftauchen. Ist das ein NTFS-Filesystem wovon du kopieren willst?
 
das hat aber nichts mit kopieren von einem anderen dateisystem zu tun.
kann man auch so probieren, neue textedit datei, sicher als wetten dass und dann noch eine neue mit sichern als wetten daß.
auf APFS sagt der, die datei existiert schon.
auf HFS kein problem.
 
Doch, habe ich schon erlebt. Ich habe sogar eine Platte hier wo ich zwei Order drauf habe die vorne gleich anfangen und hinten 2 Buchstaben anders sind. Auf dem Mac sehe ich beide und auf einem Windows-Rechner immer nur eine von den beiden. Mal die eine und mal die andere. Und die hat keine Sonderzeichen. Sonderzeichen ist oftmals ein Problem wenn man unterschiedliche Systeme oder Filesysteme benutzt. Oder zwischen unterschiedlichen Sprachen. Darum gibt es ja auch keine Internetseiten mit Sonderzeichen.
 
das hat aber nichts mit kopieren von einem anderen dateisystem zu tun.
kann man auch so probieren, neue textedit datei, sicher als wetten dass und dann noch eine neue mit sichern als wetten daß.
auf APFS sagt der, die datei existiert schon.
auf HFS kein problem.
OK, dann liegt es offenbar daran und ich muß dann alle 'Duplikate' von Hand bereinigen...
 
Ja, es liegt am APFS Dateisystem, welche eine andere Unicode-Normalisierung als das vorige HFS+ verwendet.
Danke für die Links. Ganz verstanden habe ich es aber noch nicht:

ß in s + s zu zerlegen (so wie im Beispiel fft in f + f + t), und dass diese Zerlegung dann zur Interpretation von Namensdopplern (weiß.txt und weiss.txt) führt, kann ich noch nachvollziehen – eine Ligatur wird in die Einzelbuchstaben zerlegt.

Aber ä in a + ¨ zu zerlegen führt ja weiterhin zu zwei unterschiedlichen Zeichenketten: wasser.txt und (wässer.txt zu) wa¨sser.txt, die so aber immer noch unterschiedlich sind – und zu keinem Kopierproblem führen sollte.
 
Das kommt halt drauf an, was man bezwecken will.

Die Normalisierung bei APFS ergibt eben unabhängig davon, wie die interne Representation des Wortes codiert ist, immer die das gleiche Ergebnis. In deinem Fall also ist 'wässer' und (anders codiert) 'wa"User' eben identisch. Optisch sieht es ja auch identisch aus.

Zu Zeiten von HFS+ waren die Dateien "Café" und "Café" unterschiedlich, wenn sie intern unterschiedlich codiert wurden, obwohl sie identisch ausgesehen haben. Das hat in der Software-Entwicklung durchaus zu Problemen geführt, wenn z.B. Bash-Scripts, welche die Datei 'Café' kopieren wollten, nicht funktioniert haben, weil die Codierung des Bash-Scriptes in UTF-8 erfolgte, der Dateiname aber in utf8-macos codiert war. Die Normalisierung löst das alles. Es gibt immer das identische Ergebnis, egal welche Zeichencodierung verwendet wird.
 
  • Gefällt mir
Reaktionen: dg2rbf
Zurück
Oben Unten