Verzeichnisse vergleichen fehlerhaft? --> Grund gefunden?

[Lanxy]

Hallo,
ich vergleiche Verzeichnisse mit <Shift><F2>. Die jeweils neueren Dateien werden auf beiden Seiten markiert. Wenn eine Datei im anderen Fenster fehlt, wird diese ebenfalls markiert.

Klappt prima und spart mir viel Zeit.

Nun habe ich einen Fall, bei dem die gleiche Datei links UND rechts markiert wird. Das dürfte doch eigentlich nicht vorkommen. Bei unterschiedlicher Schreibweise müssten zwar beide Dateien markiert werden (weil ja dann das Gegenstück eigentlich fehlt). Dies ist jedoch sicher nicht der Fall. Schreibweise ist 100%ig gleich.

Bin ratlos, weil ich dem Ergebnis des Vergleichs nicht mehr trauen kann.

Wo liegt der Fehler? Bei mir oder beim TC?

Gruß
Wolfgang

Edit: Der Zeitstempel der "verdächtigen Dateien unterscheidet sich nur bei den Sekunden. Dies sehe ich, wenn ich die mir die Dateiattribute ansehe. Kann es sein, dass bei obigem Vergleich die Zeit als gleich angesehen wird und dann (weil Dateigröße unterschiedlich) beide Dateien markiert werden?

Falls ja, wäre eine Änderung des Vergleichs möglich und sinnvoll? Für mich ja!

[Horst.Epp]

Verzeichnisse lassen sich doch viel besser mit der Funktion Synchronize Dirs vergleichen.

[Lanxy]

Verzeichnisse lassen sich doch viel besser mit der Funktion Synchronize Dirs vergleichen.

Verzeichnisse Synchronisieren kenne ich. Ist für mich jedoch nicht besser, weil ich die Dateien nicht kopiere, lösche etc.

Ich muss die Dateien dann in Word bearbeiten und das kann ich doch nicht aus dem "Synchro-Fenster". Zudem hat bei obiger Problemstellung auch das Synchronize die "neuere" Datei nicht erkannt.

[Horst.Epp]

Wie steht denn die Option "Ignore 1 hour time delay" ?

[Lanxy]

Hmmm, ich habe zwar an dieses Problem gedacht, muss aber gestehen, dass ich gar nichts von so einer Option in TC wusste. Da beide Dateien auf dem selben Server liegen, dürfte das eigentlich keine Rolle spielen. Da ich jedoch nicht ausschließen kann, dass eine Datei auf den Server kopiert wurde wird es doch wieder interessant.

Ich werde es aber morgen am Arbeitsplatz sofort prüfen und das Ergebnis posten.

Vielen Dank jedenfalls für den Hinweis!

Edit: Aber selbst wenn: Müsste dann nicht eine Datei als neuer erkannt werden (selbst wenn es wegen falscher Zeitzone die falsche ist)?

[karlchen]

Hallo, Wolfgang.

Edit: Der Zeitstempel der "verdächtigen Dateien unterscheidet sich nur bei den Sekunden. Dies sehe ich, wenn ich die mir die Dateiattribute ansehe. Kann es sein, dass bei obigem Vergleich die Zeit als gleich angesehen wird und dann (weil Dateigröße unterschiedlich) beide Dateien markiert werden?

Problem bestätigt und reproduziert.
Betrifft die Funktionen: Verzeichnisse vergleichen und Verzeichnisse synchronisieren.

Linke Datei:

Code: Select all

C:\Users\karl\plugtmp\plugin-crossdomain.xml	102	10.04.2010 11:34:23	-a--

Rechte Datei:

Code: Select all

C:\Users\karl\plugtmp-1\plugin-crossdomain.xml	104	10.04.2010 11:34:26	-a--

Beim Vergleichen beider Verzeichnisse (<Shift><F2>) werden solange beide Dateien rot markiert, solange die neuere Datei weniger als 4 Sekunden neuer ist.
Ab einer Zeitdifferenz von 4 Sekunden wird nur noch die rechte Datei rot markiert (korrekt: die Datei ist um 2 Bytes ergänzt worden und der Zeitstempel kunstvoll zurückgedreht für diesen Test)

Bei der Funktion Verzeichnisse vergleichen sind die Dateigrößen irrelevant, es wird nur nach Dateinamen und letztem Änderungszeitstempel (Dateidatum und -zeit) verglichen.

Hinweis:

Die Funktion Verzeichnisse synchronisieren hätte dich im vorliegenden Fall auch nicht weitergebracht. Auch bei ihr muß die neuere Datei mindestens 4 Sekunden neuer sein als die ältere, um als neuer erkannt zu werden und entsprechend die Kopierrichtung zu bestimmen.

Testumgebung:

Windows 7 Home Premium, 64-bit
Dateisystem NTFS (Zeitstempel sekundengenau)
Total Commander 7.55a (erkennt neuer ab 4 Sek. Differenz)
Total Commander 7.50a (erkennt neuer ab 4 Sek. Differenz)
Total Commander 7.04a (erkennt neuer ab 3 Sek. Differenz)

Grüße
Karl

[Lanxy]

Hallo Karl,

super!
Vielen Dank für Deine Recherchen und die Antwort. Das hilft mir sehr.

Viele Grüße
Wolfgang

[karlchen]

Hallo, Wolfgang.

War doch mal interessant, herauszutüfteln, ab wann 2 Dateien für den Total Commander unterschiedlich alt sind.

Mein Gedächtnis gaukelt mir zwar vor, ich könnte dazu schon mal was gelesen haben, leider gaukelt es mir nicht vor, wo und was genau. Da werde ich also mal die Forumssuche bemühen müssen.

Es wäre nämlich interessant zu wissen, ob die 3 Sekunden Zeitdifferenz bewußt als Toleranz eingebaut worden sind, oder ob das schlicht und ergreifend ein Fehler beim Vergleichen der letzten Änderungszeiten ist.

Grüße,
Karl

[JOUBE]

Es wäre nämlich interessant zu wissen, ob die 3 Sekunden Zeitdifferenz bewußt als Toleranz eingebaut worden sind

Vermutlich. Denn - wenn ich mich richtig erinnere - wird im FAT-Dateisystem das filedatetime von allen Betriebssystemen, die FAT verwenden, "gepackt" abgespeichert (wurde so entwickelt um Platz in der FileAllocationTable (FAT) zu sparen) [1].

Das hat zur Folge, dass das filedatetime dort nicht sekundengenau sondern "2 Sekunden genau" abgespeichert wird. Die 3 Sekunden ergäben sich dann aus +/-1.

Beim Vergleich einer Datei auf einer (zum Beispiel) internen NTFS-Platte und einer externen USB-Platte im FAT-Format gäbe es also bei durchschnittlich 1/2 der Dateien eine Ungleichheit, obwohl sie gerade eben erst von intern nach extern kopiert wurden. Das gleiche trifft auch auf NAS-Systeme zu, die Linux mit Samba und FAT verwenden.

Die beschriebene Problematik ist heute unter anderem wegen SD-Karten (mit FAT) usw natürlich noch hochaktuell. UU kann das verwendete Dateisystem vom TC auch gar nicht ermittelt werden.

JOUBE

[1] Siehe auch: de.wikipedia.org/wiki/File_Allocation_Table: "Die Auflösung der Sekunden beträgt 2 s (0..29)"

[JOUBE]

Nun habe ich einen Fall, bei dem die gleiche Datei links UND rechts markiert wird.

Dieser Fall tritt bei mir sehr oft ein und ich finde dabei die Behandlung durch denTC perfekt.

Oft vorkommente Fälle:
- Weil ich für das interne "Zippen" eingestellt habe, dass als FileDatetime des gesamten Archivs das der neuesten Datei im Archiv genommen werden soll (Konfiguration->Zip-Packer->ZIP-Datum=das der neuesten Datei) gibt es Unterschiede zwischen rechts und links immer dann, wenn ich auf einer Seite noch eine Datei hineinpacke, die älter ist als die neueste Datei im Archiv.(Beispiel: zu einem Archiv mit aktuellen GPS-Tracks packe ich noch eine ältere, abgespeicherte Wetterinformations-Datei dazu.) Dann tritt der Fall ein, dass zwar Archiv-DatumZeit rechts und links exakt gleich bleibt, aber eine Datei grösser ist, die Dateien also verschieden sind. Wie soll dann der Tc entscheiden, welche Datei die aktuellere Datei ist, die die andere überschreiben soll? (Denn vielleicht wurde ja gerade bewusst eine Datei, die älter ist als die aktuellste im Archiv, herausgelöscht). Also werden beide Dateien auf beiden Seite markiert. Und das ist genau richtig.

- Mein GPS-Gerät (kein "Navi") setzt bei den täglich auf seiner internen micro-SD-Karte neu angelegten Track-Dateien gar kein FileDatumTime. Der TC, in den man die Karte als Laufwerk mappen kann, versucht dann ein Datum gemäss FAT-Spezifikation anzunehmen (1.1.80 und auf dem Laufwerk anzuzeigen) und setzt - richtig - beim Kopieren auf den PC das aktuelle Datum ein. Dieses Datum setzte ich dann auch gleich mit dem Tc für die Dateien auf der Micro-SD-Karte. Wenn nun nach dem Abkoppeln des GPS-Geräts von Pc der Track vom aktuellen Tag auf der Micro-SD fortgeschrieben wird, bleibt das Filedatetime einfach unverändert. Später, beim erneuten Vergleich mit dem Tc sind dann nur die Datei-Grössen unterschiedlich und beide Seiten werden markiert.

Mitdenken ist angesagt.

JOUBE