Dateiattrib."Letzte Änderung" ändert sich bei umou

chamaeleon879 · 16 Mai 2007

Folgendes mehr als kurioses Problem

Ich habe ein Programm geschrieben, welches unter anderem zwei identische Dateien anhand von der letzten Veränderung (lastModifie) vergleicht. Die Methode In JAva gibt mir einen LONG - Wert zurück, den man dann vergleichen kann. Soweit so gut.

Wenn ich nun eine Datei von einem HDD Laufwerkt mit einer Datei auf einem USB Stick vergleiche findet das Programm einen Unterschied im Long - Wert von genau 1000.
Daraufhin wird die ältere Datei von beiden durch die aktuellere ersetzt. Das ist ja jetzt noch ok.
Synchronisiere ich die beiden Dateien wieder, solange der USB Stick eingesteckt bleibt, zeigt das Programm "Beide LONG Werte als Identisch an. Was ja auch stimmt. Dies kann ich beliebig oft durchführen und das Ergebnis ist immer korrekt.

Jetzt zum Witzigen:
Stecke ich den USB Stick aus (Sicher Entfernen OpenSuse 10.2) und stecke ich Ihn wieder an und synchronisiere ich dann diese Dateien wieder, stimmt der Long Wert der "letzten Änderung" um den Wert von 1000 nicht. Ich könnte es ja verstehen, wenn dies bei allen Dateien so wäre. Aber ich habe festgestellt, dass es nur bei einigen Dateien der Fall ist und nicht bei allen.
Es liegt also definitiv an der Datei bzw. an dem unmount Vorgang.
Hier mal die Ausgabe des Programms zum besser verstehen.

1. Vergleichsvorgang:
s > d source: 1178268823000destination: 1178268822000
s > d source: 1177348543000destination: 1177348542000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348543000destination: 1177348542000
s > d source: 1177348543000destination: 1177348542000

D.h. Es wurden 11 Dateien Gefunden, die unterschiedlich sind.Somit werden sie kopiert. bzw. ersetzt.
Vergleiche ich jetzt nochmal, steht in der Liste nichts mehr, da ja alle Dateien den identischen Long wert haben.

so jetzt mache ich einen umount (sicher Entfernen) bei meinem USB Stick
Danach stecke ich Ihn wieder ein und die Ausgabe sieht wieder wie folgt aus:

s > d source: 1178268823000destination: 1178268822000
s > d source: 1177348543000destination: 1177348542000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348545000destination: 1177348544000
s > d source: 1177348543000destination: 1177348542000
s > d source: 1177348543000destination: 1177348542000

Wohl gemerkt, es sind weit mehr als 11 Dateien die Verglichen werden, aber eben nur Bei diesen tritt das Problem auf. Es handelt sich zudem um unterschiedliche Dateitypen
(odt, pdt,xls)

Also wenn das nicht komisch ist.

Wei jemand von euch was OpenSuse 10.2 damit zu tun haben könnte ??? ein Indexdienst oder was weiß ich. Vielleicht liegt es auch an dem umount vorgang an sich.

Also ich habe echt keine Idee mehr.

regexer · 21 Mai 2007

Erstmal nehme ich an, dass es sich bei den 1000 um Tausendstel Sekunden handelt, oder? Also reden wir über eine Zeitdifferenz von 1 Sekunde.

Dann hätte ich noch zwei Fragen:
- Sind immer dieselben Dateien davon betroffen, oder ist das immer unterschiedlich?
- Sind die betroffenen Dateien auf dem USB-Stick 1 Sekunde älter oder die auf der HDD oder ist das auch jedesmal anders?

Die einzige Ursache, die ich mir Moment hier vorstellen kann, sind die eventuell unterschiedlichen Filesysteme. Vielleicht rechnet eines Sekundengenau und das andere in Bruchteilen von Sekunden. So würde ein Rundungsfehler zustandekommen...

chamaeleon879 · 21 Mai 2007

Erstmal nehme ich an, dass es sich bei den 1000 um Tausendstel Sekunden handelt, oder? Also reden wir über eine Zeitdifferenz von 1 Sekunde.

korrekt

Allerdings scheint mir 1 sek. für einen Zeitstempel relativ lange.

Sind immer dieselben Dateien davon betroffen, oder ist das immer unterschiedlich?

Es sind immer die identischen Dateien betroffen.
Ich habe die Synchronisation auf einem Rechner ausprobiert, bei dem der USB Stick und die HDD im FAT format formatiert waren. Da trat das Problem nicht auf. Komischer Weise, sind die "alten" Dateien von dem 1000Problem nicht betroffen. Es scheint nur die Dateien zu betreffen, welche ich kürzlich erstellt habe nach dem ich die fat Platte in eine ext2 Platte geändert habe.

Sind die betroffenen Dateien auf dem USB-Stick 1 Sekunde älter oder die auf der HDD oder ist das auch jedesmal anders?

Die auf dem USB STick sind 1 sek jünger. Es werden also die Zeitstempel auf dem Stick geändert, ABER NUR die NEU angelegten Dateien!!
Was mir aber sehr merkwürdig erscheint ist, dass das Problem erst dann auftritt, wenn ich den USB Stick unmounte. D.h. dass (wer auch immer) der Zeitstempel erst beim Unmounten um genau 1000 zurückgesetzt wird! solange der USB Stick gemountet ist kann ich synchronisieren so viel ich möchte, der Zeitstempel ist immer identisch.

Die einzige Ursache, die ich mir Moment hier vorstellen kann, sind die eventuell unterschiedlichen Filesysteme. Vielleicht rechnet eines Sekundengenau und das andere in Bruchteilen von Sekunden. So würde ein Rundungsfehler zustandekommen...

eigentlich kann es nur so sein. Aber wie gesagt, es passiert erst beim Unmount und einen Rundungsfehler im millisek. Bereich kann ich mir ja noch vorstellen, aber im sek Bereich??? finde ich schon enorm.
Nur um einen Fehler mit dem USB Stick auzuschließen, ich habe es mit zwei unterschiedlichen Probiert.

chamaeleon879 · 21 Mai 2007

ich habe jetzt mal unterschiedliche Konstellationen ausprobiert und muss meine Aussage etwas korrigieren:

der Fehler tritt auf, egal mit welchem File System Probiert habe ich bisher:

FAT -> ReiserFS
FAT -> ext3
FAT -> FAT

und das geilste daran ist folgendes:

habe zwei Unterschiedliche PC's jeweils mit OpenSuse 10.2
Ich erstelle ein Verzeichnis auf PC1 und erstelle auch eine Datei (PC1Datei.txt)
Synchronisiere ich, erscheint das Problem wie beschrieben (nach dem umount)

sodele und jetzt wechselich zu meinem anderen PC (PC2)

Zu Bemerken ist, dass die Datei PC1Datei.txt noch auf dem USB Stick ist.

Nun lege ich auch hier ein Verzeichnis an und erstelle darin eine Datei PC2Datei.txt

Nun synchronisiere ich die beiden Verzeichnisse. Es passiert logischerweise folgendes:
Die Datei PC1Datei auf dem USB Stick wird auf die Platte kopiert und die Datei von der Platte PC2Datei.txt wird auf den USB Stick kopiert.

synchronisiere ich erneut, sind alle Dateien identisch...

SO und wenn ich nun umount mache und danach erneut synchronisere passiert folgendes:

PC1Datei.txt ist IDENTISCH hier wir also kein 1000 unterschied angezeigt.
nur bei der PC2Datei.txt wir der unterschied festgestellt.!!!!! also nur bei der Datei, welche auf dem Rechner erstellt wurde!!!!!!!

Geil oder ?

chamaeleon879 · 21 Mai 2007

Unter Windows tritt das Problem nicht auf.
Kubuntu zeigt das gleich Problem

Es ist wirklich so, dass es ausschließlich die Dateien betrifft, welche auch dem jeweiligen System erstellt worden sind.

Wurden Sie auf einem anderen System erstellt, wird nichts geändert.

regexer · 21 Mai 2007

Stimmt, eine Sekunde ist lang in der Welt der Computer. Mit Rundungsfehler meinte ich aber, dass die Filesysteme eventuell gar keine Bruchteile von Sekunden ablegen. Was macht Linux mit einer Datei auf FAT, wenn die Modification Time 12:38:01.51 ist? Legt es 12:38:01 ab? Oder 12:38:02?

Hast du einmal stat verwendet, um dem Problem auf die Spur zu kommen? So müsste man zumindest klären können, ob meine These stimmt oder nicht...

chamaeleon879 · 21 Mai 2007

also ich habe jetzt mal folgendes gemacht.
per Java Code habe ich folgende Dateien erstellt:

* sourcefile1.txt --> mit dem Wert:1177588693999
* destinationfile2.txt --> mit dem Wert:1177588693111

Ergebnis von stat war:

Code:

user@OpenSuse:~> cd '/media/USBBLACK/'
user@OpenSuse:/media/USBBLACK> stat destinationfile2.txt
  File: „destinationfile2.txt“
  Size: 0               Blocks: 0          IO Block: 2048   reguläre leere Datei
Device: 821h/2081d      Inode: 2241        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  markus)   Gid: (    0/    root)
Access: 2007-05-21 20:01:49.000000000 +0200
Modify: 2007-04-26 13:58:13.000000000 +0200
Change: 2007-05-21 20:01:49.000000000 +0200
user@OpenSuse:/media/USBBLACK> stat sourcefile1.txt
  File: „sourcefile1.txt“
  Size: 0               Blocks: 0          IO Block: 2048   reguläre leere Datei
Device: 821h/2081d      Inode: 2240        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  markus)   Gid: (    0/    root)
Access: 2007-05-21 20:01:49.000000000 +0200
Modify: 2007-04-26 13:58:13.000000000 +0200
Change: 2007-05-21 20:01:49.000000000 +0200
user@OpenSuse:/media/USBBLACK>

Somit wird meiner Meinung nach nicht gerundet, sondern einfach abgeschnitten
NACH einem umount con Stats sieht das Ergebnis folgendermaßen aus:

Code:

user@OpenSuse:~> cd '/media/USBBLACK/'
user@OpenSuse:/media/USBBLACK> stat destinationfile2.txt
  File: „destinationfile2.txt“
  Size: 0               Blocks: 0          IO Block: 2048   reguläre leere Datei
Device: 821h/2081d      Inode: 2294        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  markus)   Gid: (    0/    root)
Access: 2007-05-21 00:00:00.000000000 +0200
Modify: 2007-04-26 13:58:12.000000000 +0200
Change: 2007-05-21 20:01:49.000000000 +0200
user@OpenSuse:/media/USBBLACK> stat sourcefile1.txt
  File: „sourcefile1.txt“
  Size: 0               Blocks: 0          IO Block: 2048   reguläre leere Datei
Device: 821h/2081d      Inode: 2293        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/  markus)   Gid: (    0/    root)
Access: 2007-05-21 00:00:00.000000000 +0200
Modify: 2007-04-26 13:58:12.000000000 +0200
Change: 2007-05-21 20:01:49.000000000 +0200
user@OpenSuse:/media/USBBLACK>

Also irgendwie ist das alles merkwürde. Vor allem auch, dass es an das Betriebssystem bzw. Rechner gebunden ist...

regexer · 21 Mai 2007

Hmmm, richtig schlau werde ich daraus auch nicht. Vielleicht werden diese Zeiten irgendwo in einer Art Filesystem-Cache gehalten...

Denn ist dir folgendes aufgefallen: Die Access-Time wird anscheinend nur Tagesgenau abgelegt. Nach dem Umount ist die Zeit jedenfalls 00:00.

Hast du die Files mit Java direkt auf dem USB-Stick erzeugt? Wenn nein würde mich bloß noch die stat-Ausgaben von deinem HDD interessieren.

chamaeleon879 · 22 Mai 2007

also die Files wurden direkt auf dem USB erzeugt. (Code siehe unten)

Ich habe die datei sorucefile1.txt allerdings auch auf der HDD.die Ausgabe von stat lautet wie folgt:

Code:

  File: „sourcefile1.txt“
  Size: 0               Blocks: 0          IO Block: 4096   reguläre leere Datei
Device: 811h/2065d      Inode: 4207306     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  markus)   Gid: (  100/   users)
Access: 2007-05-21 19:55:37.000000000 +0200
Modify: 2007-04-26 13:58:13.000000000 +0200
Change: 2007-05-21 19:55:37.000000000 +0200

Somit bleibt die Zeit hier korrekt, auch nach einem Neustart

Code:

    public static void main(String[] args) {
        Date d1 = new Date();
        Date d2 = new Date();
        GregorianCalendar g = new GregorianCalendar();
        
        GregorianCalendar g1 = new GregorianCalendar();
        Long l = new Long("111");
        long l1 = l.parseLong("1177588693999");
        g.setTimeInMillis(l1);
        long l2 = l.parseLong("1177588693111");
        g1.setTimeInMillis(l2);
        
        d1.setTime(l1);
        d2.setTime(l2);
        System.out.println(g.getTime()+"\n"+g1.getTime());

        File f1 = new File("/media/USBBLACK/sourcefile1.txt");
        File f2 = new File("/media/USBBLACK/destinationfile2.txt");        
        System.out.println("sourceFileLastMod: "+f1.lastModified());
        System.out.println("destinFileLastMod: "+f2.lastModified());
        if (f1.exists()){
            //f1.setLastModified(l1);
        }
        else {
            try {
                f1.createNewFile();
            } catch (IOException ex) {
                ex.printStackTrace();
            }
            f1.setLastModified(l1);
        }
        
        if (f2.exists()){
            //f2.setLastModified(l2);
        }
        else {
            try {
                f2.createNewFile();
            } catch (IOException ex) {
                ex.printStackTrace();
            }
            f2.setLastModified(l2);
        }     
        
        System.out.println("sourceFileLastMod: "+f1.lastModified());
        System.out.println("destinFileLastMod: "+f2.lastModified());
    }

Also das mit dem Cache habe ich mir auch schon überlegt. Allerdings finde ich dann die Genauigkeit von genau 1sek. merkwürdig. Meinem Verständnis nach, müsst bei einem Cache eine größere Streuung auftreten.

Ich sehe schon, ich werde für mein Programm eine Tolleranz von 1 sek in Kauf nehmen müssen, obwohl mir das nicht wirklich gefällt ;-(

regexer · 22 Mai 2007

Wenn du noch Lust hast, mach doch bitte folgendes (und diesmal ganz ohne java):

Code:

cd /HDD
stat -f . --format="%T"
stat --format="%y %Y %n" sourcefile1.txt

cp -p sourcefile1.txt /media/USBBLACK
cd /media/USBBLACK
stat -f . --format="%T"
stat --format="%y %Y %n" sourcefile1.txt

umount ...
mount ...
stat --format="%y %Y %n" sourcefile1.txt

panamajo · 22 Mai 2007

notoxp schrieb:
dass die Filesysteme eventuell gar keine Bruchteile von Sekunden ablegen. Was macht Linux mit einer Datei auf FAT, wenn die Modification Time 12:38:01.51 ist?

FAT Dateisyssteme haben für die Uhrzeit der letzten Änderung nur eine Auflösung von 2 Sekunden, siehe http://en.wikipedia.org/wiki/Vfat#Directory_table

regexer · 22 Mai 2007

panamajo schrieb:
FAT Dateisyssteme haben für die Uhrzeit der letzten Änderung nur eine Auflösung von 2 Sekunden, siehe http://en.wikipedia.org/wiki/Vfat#Directory_table

Danke für den Link. Also war meine Vermutung zumindest nicht ganz falsch. Die Sekunden werden in 4 Bit abgelegt. Das bietet natürlich nur Platz für 32 Sekunden. Dafür sind laut Beschreibung die Stunden mit 5 Bit abgelegt --> Aua!

panamajo · 22 Mai 2007

notoxp schrieb:
Dafür sind laut Beschreibung die Stunden mit 5 Bit abgelegt --> Aua!

Wahrscheinlich steuert das 5. bit ob die 4 vorherigen einen 24 Stunden Wert oder einen 12 Stunden + AM/PM repräsentieren LOL

chamaeleon879 · 22 Mai 2007

WOW, was für ne Sch......
aber vielen Lieben Dank euch beiden für die Unterstützung.
Komisch ist doch aber, dass ich unter Windows das Prob. nicht habe. und das Prob auch von FAT zu FAT auftritt. (unter Linux)

naja egal, ich werde mich wohl damit abfinden müssen einen Bug in mein Programm zu implementieren *lol

Hier trotzdem noch die Ausgabe

@notoxp

hier die Ausgabe:
markus@OpenSuse:~> stat -f . --format="%T"
ext2/ext3
markus@OpenSuse:~> stat --format="%y %Y %n" sourcefile1.txt
2007-05-22 19:26:56.000000000 +0200 1179854816 sourcefile1.txt
markus@OpenSuse:~> cp -p sourcefile1.txt /media/USBBLACK
markus@OpenSuse:~> cd /media/USBBLACK
markus@OpenSuse:/media/USBBLACK> stat -f . --format="%T"
msdos
markus@OpenSuse:/media/USBBLACK> stat --format="%y %Y %n" sourcefile1.txt
2007-05-22 19:26:56.000000000 +0200 1179854816 sourcefile1.txt
markus@OpenSuse:/media/USBBLACK> cd ~
markus@OpenSuse:~> cd /media/USBBLACK
markus@OpenSuse:/media/USBBLACK> stat --format="%y %Y %n" sourcefile1.txt
2007-05-22 19:26:56.000000000 +0200 1179854816 sourcefile1.txt
markus@OpenSuse:/media/USBBLACK>

regexer · 23 Mai 2007

Komisch ist doch aber, dass ich unter Windows das Prob. nicht habe.

Bei FAT <--> FAT dürfte es auch keine Probleme geben, da beide Filesysteme gleich unwissend sind. Hast du auch NTFS <--> FAT probiert?

chamaeleon879 schrieb:
Hier trotzdem noch die Ausgabe

Klar! Hier funktioniert es wieder, da es eine gerade Anzahl von Sekunden sind. Hätte man auch so draufkommen können, da in deinem ersten Beitrag alle Sekunden ungerade waren...

chamaeleon879 · 23 Mai 2007

Also unter Windows habe ich überhaupt keine Probleme.
Was ich noch herausgefunden habe ist allerdings, dass es ausschließlich an der Mehtode setLastModified liegt.
Logisch, da hier auch hundertstel sekunden gesetzt werden.

Um ehrlich zu sein, habe ich zwar verstanden, dass es an dem FAT Dateisystem liegt. Soweit ok.

Aber warum das Problem in so komischen konstallationen auftritt und auch nur auf ein BS bezogen und dann auch nur unter Linux, verstehe ich noch nicht so ganz.

Aber ist auch egal, habe mein Programm jetzt so geändert, dass es +-1 sek. Tolleranz hat und jetzt funzt es wunderbar unter Linux.

wer interesse hat *g
http://ifsync.sourceforge.net

Auf jeden Fall vielen Dank für eure Zeit!!!! supger genial von euch, denn jetzt habe ich wenigstens ein wenig Durchblick
MERCI!!!

regexer · 23 Mai 2007

chamaeleon879 schrieb:
Aber warum das Problem in so komischen konstallationen auftritt und auch nur auf ein BS bezogen und dann auch nur unter Linux, verstehe ich noch nicht so ganz.

Benutzt du auf deinem Windows-HDD das Dateisystem NTFS oder FAT? Wie bereits weiter oben erwähnt: Wenn du auf dem Windows-HDD ebenfalls FAT benutzt, ist es klar, dass es unter Windows keine Probleme gibt. Ungerade modified-Sekunden kommen dann nämlich gar nicht vor - weder bei der source noch bei der destination.

Aber ist auch egal, habe mein Programm jetzt so geändert, dass es +-1 sek. Tolleranz hat

Sorry für meine Besserwisserei

...
Es hätte doch -1 genügt.
+1 sek kann nach meinem Verständnis nicht vorkommen.

chamaeleon879 · 23 Mai 2007

ich benutze NTFS auf der HDD Seite.
Aber du hast schon recht, bei FAT und FAt dürfte es keine Prob. geben.
Unter Linux gibt es diese aber trotzdem. Also ich vermute dass deine theorie mit dem cache stimmt. was anderes kann ich mir nimmer vorstellen

zu dem +-1, ich muss (leider) so prüfen, da es bei meinem Programm ncht nur sein kann, dass ich vergleich kleiner datei mit größerer (hier kommt natürlich raus, dass ich nur -1 bräuchte) sonder es könnte ja auch sein, dass ich anders herum vergleich, also die größere mit der kleineren. und da ich die tollerenz nur auf einer Seite programmiere muss ich diese auf +-1sek. Programmieren.

Hoffe du hast es verstanden ;-) aber darüber habe ich gestern Abend auch schon gebrütet

regexer · 23 Mai 2007

chamaeleon879 schrieb:
ich benutze NTFS auf der HDD Seite.

Dann verstehe ich das auch nicht ... NTFS legt nämlich nach meinen Tests mindestens Sekundengenau ab.

zu dem +-1, ich muss (leider) so prüfen, da es bei meinem Programm ncht nur sein kann, dass ich vergleich kleiner datei mit größerer (hier kommt natürlich raus, dass ich nur -1 bräuchte) sonder es könnte ja auch sein, dass ich anders herum vergleich, also die größere mit der kleineren.

Naja, im Grunde genommen kommt es darauf nicht an. Ich hätte halt vor dem Vergleich alle ungeraden Sekunden auf gerade abgerundet (also -1). Aber von der Sache her kommt dasselbe heraus...

Interessanterweise wird z.B. die creation time bei FAT offenbar genauer abgelegt... Frage in den Raum: Gibt es irgendwo im Netz eine Übersicht über die Dateisysteme (vielleicht auch inklusive Exoten wie HPFS usw.) und deren Genauigkeiten bei den TimeStamps?

Ich habe zumindest mal das gefunden http://en.wikipedia.org/wiki/Comparison_of_file_systems

Hier findet man auch folgenden interessanten Satz:

Some FAT implementations, such as in Linux, show file modification timestamp (mtime) in the metadata change timestamp (ctime) field. This timestamp is however, not updated on file metadata change.

regexer · 23 Mai 2007

Ich habe jetzt erstmals dein Problem in der Praxis nachvollzogen. Ganz ohne Memory-Stick mit einer einfachen FAT32-Partiton...

Code:

user@host:/windows/E> stat -f . --format "%T"
msdos
user@host:/windows/E> touch -m -t 200705232040.13 test.txt
user@host:/windows/E> stat --format "%y %Y %n" test.txt
2007-05-23 20:40:13.000000000 +0200 1179945613 test.txt
user@host:/windows/E> cd /
user@host:/> umount /windows/E
user@host:/> mount -a -t vfat
user@host:/> cd /windows/E
user@host:/> stat --format "%y %Y %n" test.txt
2007-05-23 20:40:12.000000000 +0200 1179945612 test.txt
user@host:/>

Jetzt müsste ich für einen weiteren Test bloß noch mein Win2k booten. Aber dazu habe ich glaube ich heute keine Lust mehr

Dateiattrib."Letzte Änderung" ändert sich bei umou

Newbie

Advanced Hacker

Newbie

Newbie

Newbie

Advanced Hacker

Newbie

Advanced Hacker

Newbie

Advanced Hacker

Guru

Advanced Hacker

Guru

Newbie

Advanced Hacker

Newbie

Advanced Hacker

Newbie

Advanced Hacker

Advanced Hacker