Synchronisieren zeigt falsche Dateien als neu an

[Matt83]

Hallo Leute,

ich hab ein Problem mit meinem TC.

Ich synchronisiere meine Hörbücher von meinem Windows PC auf ein Macbook, mit dem ich per Paralles gerade auf Windows arbeite weil dort ja TC funktioniert

Ich greife also über UNC Pfad auf meinen Win7 PC zu, das ist das linke Fenster. Im rechten Fenster ist der Homepfad z:, das ist der Benutzerpfad auf der Mac-Ebene wenn man in Paralles arbeitet, und dort der Unterordner Audiobooks.

Im Screenshot werden Dateien auf der linken Seite angezeigt, die neuer oder gar nicht vorhanden sein sollen, aber das ist nicht der Fall wie der Windows Explorer den ich daneben geöffnet habe ja darstellt.

Das passiert nur bei Dateien mit Umlauten. Das ist aber kein globales Phänomen, denn es gibt noch zig Dateien die Umlaute enthalten, die er sauber auf der rechten Seite erkennt und daher nicht "aktualisieren" will.

Viele Grüße,
Matt

[Matt83]

Anbei ein Screenshot, der die ganze Sache hoffentlich verständlich macht.
h t t p : / / f s 1 . d i r e c t u p l o a d . n e t / i m a g e s / 1 5 0 2 1 2 / p 8 l 4 x a 2 u . j p g

Da ich keine Links posten darf, muss ich das hier leider so zerhackstückeln

[karlchen]

Hallo, Matt83.

Hier der Link in direkt klickbarer Form: http://fs1.directupload.net/images/150212/p8l4xa2u.jpg

Ich persönlich muß gestehen, dass ich den Screenshot mit dem Geschriebenen nicht wirklich in Übereinstimmung bringen kann.
Zum einen verdeckt das Explorer Fenster einen Teil des Total Commander Fensters. Das ist nicht hilfreich, um zu versehen, was der Total Commander erkannt hat und synchronisierenswert findet.
Zum anderen ist mir nicht klar geworden, was das Explorerfenster mit dem Synchronisieren Fenster des Total Commanders zu tun hat.
Zusätzlich würde ich im Total Commander im Synchronisieren Dialog die Anzeige von geichen Dateien ausblenden, [=] ausschalten, dafür aber die Synchronisationsrichtung von rechts nach links [<=] anzeigen lassen.
Dann könnte man sehen, ob die links grün markierten Dateinamen rechts in blau ebenfalls wieder auftauchen.

Grüße,
Karl

[Matt83]

Hallo Karl,

vielen Dank für deine rasche Antwort.

Links zb geht es um den Ordner:
Patrick Rothfuss -Die Königsmörder-Chronik\02 - Die Furcht der Weisen
Dort sind die Dateien 012 - 014 grün, also auf der rechten Seite nicht vorhanden.
Die gleichen habe ich einblenden lassen, weil diese Dateien dort ja eigentlich stehen sollten, denn das rechte Fenster zeigt ja z:\audiobooks an.
Und weil die Dateien dort nicht auftauchen, habe ich den Explorer daneben geöffnet wo man die markierten Dateien sieht, die eindeutig ja da sind.

Mit dem blauen Pfeil hab ich bisher das noch nicht so ganz verstanden. Immer wenn ich da auf Synchronisieren geklickt hatte, wurde das links immer bloß gelöscht, daher mach ich damit eigentlich gar nichts >.<

VG Matt

[Dalai]

Läuft der TC als Administrator? Wenn ja, mit welcher Freigabe ist dort Z: verbunden? Welchen SMB-Dienst verwendet der Mac (IIRC gibt's da mehrere)? Welche Dateien werden auf der rechten (blauen) Seite als einzeln angezeigt? Ich kann mir vorstellen, dass hier ein "Munging" von Umlauten stattfindet, nur dummerweise sind die Dateien auf der rechten Seite im Screenshot ja ausgeblendet...

MfG Dalai

[milo1012]

Da darfst du dich bei Apple bedanken,
weil man dort der Meinung ist nicht die NFC-Unicode-Normalisierung nutzen zu müssen.
http://de.wikipedia.org/wiki/Normalisierung_(Unicode)


So wird aus dem deutschen 'ü' dann ein

Code: Select all

0x7500 0x0803

(UTF-16 LE)
also ein kleines u mit kombinierendem diakritischen Zeichen,
obwohl man es bei NFC (Windows) einfach als

Code: Select all

0xFC00

schreiben könnte.

Wir haben das Problem hier in der Firma auch öfters...
und leider noch keine Einstellung seitens des Mac gefunden welche die Sache behebt.
Leider könnte da auch kein Plugin helfen das
die Seiten vergleicht, da der Namensvergleich Sache von TC ist.



Dass es nicht immer passiert kann daran liegen wie die Dateien zusammengestellt wurden,
also ob sie wiederum von anderer Quelle auf dem Mac gelandet sind oder manche Dateien
auf dem Mac selbst erstellt/umbenannt/verschoben wurden, etc..
Windows selbst behält nämlich die Nicht-NFC-Kodierung bei,
so dass z.B. solche Dateinamen in einem Verzeichnis parallel existieren können:

Code: Select all

ü
ü

Ich wollte schon länger mal vorschlagen dass TC die Normalisierung eingebaut bekommt,
(also dass solche Dateien in Zukunft als gleich behandelt werden)
und ich denke dieses Beispiel zeigt warum es nötig ist.

[karlchen]

Guten Morgen, milo1012.

Da darfst du dich bei Apple bedanken, weil man dort der Meinung ist nicht die NFC-Unicode-Normalisierung nutzen zu müssen. [...]

Aha! Das erklärt zum Teil, warum mir der Screenshot nicht so sehr weitergeholfen hat, zu verstehen, was vorgehen könnte.
Auf den Punkt gebracht:
Dank Apple vergleicht der Total Commander hier Äpfel mit Birnen.
OK, da es in meinem Umfeld weit und breit keine Apples gibt, wäre ich da nicht so schnell drauf gekommen.
Wieder was dazugelernt.

Ciao, Karl

[Matt83]

Hallo Milo,

vielen Dank für die Aufklärung der Sache. Jetzt weiß ich immerhin woran ich bin, wobei mir eine Lösung natürlich besser gefallen hätte weil ich z.B. irgendetwas falsch eingestellt hatte.

Und ebenfalls vielen Dank Karl und Dalai für eure Unterstützung!

[milo1012]

Jetzt weiß ich immerhin woran ich bin, wobei mir eine Lösung natürlich besser gefallen hätte

Wenn ich eine Lösung hätte würde ich sie gerne hier veröffentlichen,
nur ist das leider eine Limitierung von TC bzw. der Win-API.
Genau genommen gibt es jede Menge Programme da draußen die mit den Unicode-Normalisierungen nicht klarkommen,
das Ganze ist nämlich leider alles andere als trivial.

Bleibt nur Christian zu bitten eine Option für die Normalisierung in der nächsten Version einzubauen.

Jedenfalls können wir Apple hier nur beglückwünschen, dass sie als einzige größere Plattform nicht NFC nutzen
(genauer gesagt: das Dateisystem HFS+), denn selbst die meisten Unix-/Linux-Systeme nutzen es.
Okay, da ein Mac die typische Plattform für Designer ist sagt sich Apple wahrscheinlich deshalb sei es einfacher
für z.B. Schriftaren-Design wenn die Zeichen einzeln zusammengesetzt werden ...nur wie viele Leute tun sowas tatsächlich?

Unicode ist eigentlich eine feine Sache, aber man kann mit den kombinierenden Zeichen ziemlich viel Blödsinn anstellen,
weswegen die NFD-Form, wie sie Apple verwendet, eigentlich nicht nach außen getragen werden sollte.
Nur so als Beispiel:

Code: Select all

s̵̟̰͖͈̯͡iZ̢̲̪e̳̲̻̰̲͞  ̸̷̜̗͍̰̫̩͖ͅ  D́҉̭͍̮̥̱̞̜͟iF̳̱̪͈̭̪͙̼̹̕f̻̺̺͕̘e̡̛̬̜͙͕͔R̩͘͟En͚̻͖̠c҉͏̟̰̦͓e҉̠͙͈͕̣ͅ

#806;

[MC]

Vielleicht habe ich das noch nicht ganz verstanden - aber wenn hier der TC unter Parallels (ja, mit drittem L) läuft, und dann Dateinamen des Mac nicht so aufbereitet dass der TC sie Windows-nativ/verständlich bekommt - hat dann nicht Parallels geloost?

Oder würde es vielleicht helfen andere HFS+ Treiber, z.B. von Paragon, in diesem virtuellen Windows zu installieren?

[milo1012]

aber wenn hier der TC unter Parallels (ja, mit drittem L) läuft, und dann Dateinamen des Mac nicht so aufbereitet dass der TC sie Windows-nativ/verständlich bekommt - hat dann nicht Parallels geloost?

Nein, warum sollte sich Parallels darum kümmern?
Es ist ja gültiges Unicode, und das ist ja die Crux an der Sache.
Bei Windows und Co. kann man sämtliche Umlaute ja auch kombiniert eingeben (wenn man das möchte),
und allen Programmen ist das erstmal egal und sie lassen sie so wie sie sind, da sie nicht Wissen können ob es nun absichtlich getan wurde oder nicht.
Das Problem hat man ja auch wenn man Daten im Mac auf eine externe Festplatte/USB-Stick etc. kopiert, und diese dann
anschließend in einem Win-Rechner ausliest.
Obwohl das Dateisystem i.d.R. FAT32 (meinetwegen auch NTFS) ist und eine Normalisierung angebracht wäre passiert es eben nicht (zumindest habe ich noch keine automatische Möglichkeit gefunden).

Auch den meisten Netzwerkprotokollen ist das herzlich egal, sie schleusen die Unicode-Roh-Bytes einfach durch, da sie ja gültig sind.
Um mal diese Diskussion zu zitieren:

the kernel and filesystem don't know anything about normalisation

Hier mal eine andere Diskussion dazu, die sich mit rsync beschäftigt, und vielleicht eine Möglichkeit darstellt das Ganze zu beheben

Und hier eine offizielle Erklärung warum das HFS+ macht.

Oder würde es vielleicht helfen andere HFS+ Treiber, z.B. von Paragon, in diesem virtuellen Windows zu installieren?

Glaube ich nicht, da das beschriebene Problem ja immer das Gleiche ist.
Aber wenn jemand einen Treiber kennt der das Ganze optional macht wäre es natürlich perfekt.

[ghisler(Author)]

Wenn Sie im Synchronisiertool den blauen Button "<-" drücken, dann werden Sie sehen, dass die 3 Dateien auch rechts vorhanden sind - aber mit dem anders codierten "ü". Das Problem ist nun, dass beide Varianten gleichzeitig im selben Verzeichnis vorhanden sein können. Deshalb kann ich nicht einfach die beiden Varianten als gleich ansehen, weil es dann keine 1:1-Identität mehr gäbe (Datei könnte auf einer Seite 1x und auf der anderen 2x vorliegen).

[milo1012]

Habe ein wenig recherchiert.
Zumindest ein Inhaltsplugin ist möglich, was anzeigt ob die Dateinamen
nicht in der NFC-Form vorliegen (zumindest teilweise).
Bei der Gelegenheit kann man auch gleich die normalisierte Form zurückgeben
und sie in TC's MRT nutzen.

Info und Download

Ich hoffe es bestätigt sich meine Vermutung mit den Umlauten.
Vielleicht hatte es im OP ja auch andere Ursachen