Windows XP bringt ISO Zeitformat durcheinander

Ach Jörg.... Den ganzen Konvertierungsoverhead haven die Samba-Programmierer doch nicht dazuprogrammiert, um speziell Dir das Leben schwerer zu machen.

Wenn du jemals das zweifelhafte Vergnügen hattest, einen Server zu betreuen, der mehr als nur einen Windows-Client hatte, am besten noch mit verschiedenen lokalen Zeitzonensettings, verschiedenen Zeichensätzen und verschiedenen Versionen, wird Dir ganz schnell klar, daß es nicht so einfach ist, wie Du es Dir vorstellst.

Dann fang' mal an, da Zeitzonen und Zeichensätze umzustellen... Dazu kommt dann noch, daß Linux Schreib- und Leserechte anders verwaltet als DOS/Windows und es andere Beschränkungen zu erlaubten Zeichen in Dateinamen gibt (*?:/\.).

Welche Samba-Version hast Du denn laufen? Vielleicht gibt es da ja tatsÄchlich einen Fehler und evtl. ist der ja sogar inzwischen gefixt.

Da scheint jemand beim Standard besser mitgedacht zu haben....

_Ausgerechnet_ bei SMB? Ja klar...

Gruß, Jürgen

Joerg schrieb:

Weil die Idee von MS-DOS, die Zeit des Systems und damit auch der Dateien als lokale Zeit zu speichern statt als UTC, ziemlicher Blödsinn ist, MS aber zwecks Rückwärtskompatibilität diesen Fehler nicht mehr ausräumen wollte.

Man konnte bei MS-DOS auf diese Weise schon immer Dateien erzeugen, die an einem anderen Teil der Welt in der Zukunft lagen. Das war kein Problem, solange an einen schnellen Datenaustausch zwischen verschiedenen Teilen der Welt noch nicht zu denken war, aber diese Ära ist nun schon mehr als ein Jahrzehnt vergangen.

Selbst, wenn man nur den lokalen Rechner betrachtet, hast du Probleme mit dem DST switch. Diese beiden Dateien:

$ env TZ=Etc/UTC touch -t 200910250003 /tmp/future1 $ env TZ=Etc/UTC touch -t 200910250103 /tmp/future2

haben offensichtlich zwei verschiedene Zeitstempel. Wenn man sie sich als ,,Küchenzeit'' ansieht, sehen sie jedoch gleich aus; ihre Zeitstempel sind in diesem System nicht mehr unterscheidbar:

$ ls -l /tmp/future1 /tmp/future2

-rw-r--r-- 1 j wheel 0 Oct 25 02:03 /tmp/future1

-rw-r--r-- 1 j wheel 0 Oct 25 02:03 /tmp/future2

Glücklicherweise speichert Unix (einschließlich seines Dateisystems) die Zeitstempel jedoch nicht in Küchenzeit, sodass die zu Grunde liegenden Dateiobjekte unterscheidbare Zeiten besitzen. Das kann man sehen, wenn man für die Darstellung die Zeit auf UTC schaltet:

$ env TZ=Etc/UTC ls -l /tmp/future1 /tmp/future2

-rw-r--r-- 1 j wheel 0 Oct 25 00:03 /tmp/future1

-rw-r--r-- 1 j wheel 0 Oct 25 01:03 /tmp/future2

Damit weiß zum Beispiel ein Backup-Programm eindeutig, ob es eine in diesem Zeitraum entstandene Datei nun nochmal sichern muss oder nicht.

Auf die Gefahr mich zu widerholen:

a. Warum vermasselt die Samba-Kiste die Zeitangabe und _alle_ Windows-Kisten nicht?

b. Warum kappt die Samba-Kiste Executable-Flags und alle Windows-Kisten lassen die einfach in Ruhe? Das fuehrt dazu, dass ein Doppelklick auf einen *.doc File auf dem Sama-Kaeschtle zu einer Fehlermeldung fuehrt, auf den Windows-Kisten korrekterweise den File in den Word Processor oeffnet.

Aber offensichtlich verbockt.

Files gehen hier zwischen mir und Kunden in 6-7 Zeitzonen hin und hier. Seltsamerweise gibt's damit kein Problem. Ausser wenn sie auf dem Samba-Server waren. Hmm ...

Merkwuerdig ist auch, dass meine Web Site und damit auch der File Bereich auf einem unixoiden Rechner liegt und die Zeit nicht durcheinanderbringt. Samba aber schon.

Gefixt? Also hatten sie es doch verbockt? Axel meinte das muesse unbedingt und ganz allein an Billy's Leuten liegen :-)

Ich muss mal nachsehen ob es ein Patch gibt und wie man das da draufspielt. Wohl ist mir bei sowas allerdings nicht.

Das denke ich auch.

Sieh es mal rein von der User Seite aus: Da sind haufenweise Windows Rechner und nie gibt es ein Zeit-Datum Problem. Nun gibt es ein einzelnes Linux-Geraet und das haut die Zeit voll durcheinander. Was soll Otto Normal-User nun denken? Erinnert mich irgendwie an den Witz vom Geisterfahrer. "Einer? Hoe! Ganz viele sind das ..."

=20

Ich verstehe nicht, was Du meinst. Windows kennt gar kein "executable"-Flag. Wenn Du also von einer Windows-Kiste aus auf das Samba-Laufwerk zugreifst, muss sich der Word Processor =C3=B6ffnen, es se= i denn, die Windows-Kiste ist falsch konfiguriert. Ich verstehe nicht, in wie fern das anders ist, als wenn Du die Daten =C3=BCber Netz auf eine= m Windows-Server speicherst.

Oder hast Du =C3=84pfel und Birnen verglichen? Samba missbrauchst das executable-flag auf Unix-Seite (was Windows-Clients aber nie zu sehen bekommen!) um das Archiv-, System- und Hidden-Bit zu emulieren, die es unter Linux gar nicht gibt. Das kann man abschalten, steht in der manpage zu smb.conf, suche nach "map archive".

Wenn Du das Archiv-Bit brauchst, das "executable"-Bit nervt, dein Kernel neu genug ist und mit den richtigen Einstellungen (mit extended Attributes) kompiliert ist [die meisten Distri-Kernels haben das], das Dateisystem, auf dem Du speicherst "extended attributes" kann und die mount-Option "user_xattr" bei dem Dateisystem gesetzt ist, kannst Du mit "store dos attributes =3D yes" die Emulation der Attribute aus den Unix-Permissions raus in ein extended attribute schieben, was sauberer w=C3=A4re.

Gru=C3=9F, Michael Karcher

Das ist fuer mich ganz praktisch. Ich kann dem Kunden ohne Rechnerei sagen, dass der File supergizmo.sch bei ihm abends im 1930h abgespeichert wurde. Egal was mein Computer fuer eine Zeit anzeigt.

Hier ganz einfach geloest: Backup immer voll, und wenn teilweise dann nimmt man einfach ein 24h Periode laenger mit rein. Wenn ich natuerlich einen Kunden auf dem Mars haette, ja dann ...

So einfach ist das nicht. Diese LAN-Server lassen nur Passwort- und sonstige Konfiguration zu, an das OS da drin kommt man nicht ran. Jedenfalls nicht mit Hausmitteln, und ich moechte auch nicht jedesmal im Motor rumbasteln muessen nur damit etwas so funktioniert wie es das bei den Win-Rechner einfach ganz von allein tut. Ist so aehnlich wie in einem Linux Forum jemandem empfohlen wurde, das "mal eben" alles neu zu kompilieren ;-)

Otto Normal-User interessiert eigentlich nur, was wo geht und was nicht. Bei (allen) Windows PC kann ich auf einen *.doc File klicken und der File oeffnet sich im Word Processor (funzt). Auch wenn der File auf einem anderen Rechner im Netzwerk liegt. Beim Samba Kaestchen kommt die Fehlermeldung "... is not a valid Win32 application" (funzt nicht). Ok, damit kann man irgendwie leben, aber die Sache mit dem kaputten Datum/Zeit ist schon aetzend.

mit "LAN Server" meinst du vermutlich ein NAS. Die gibt es auch auf Windows-Basis, ganz ohne Samba & Co., nur "unwesentlich" teurer. Man muss halt wissen, was man will - basteln oder arbeiten.

Gruß

Klaus

Ja, brauchte damals schnell eine und wollte das damals alles vor dem

Wenn du nur eine Möglichkeit zur Datensicherung brauchst, kannst du ja solange einfach eine externe USB-Platte dranhängen. Wenn die in einem anderen Raum stehen soll (wg. der Sicherheit), einfach mit einem Silex SX2000U2 über's LAN verbinden. Das läuft ganz transparent & kostet nicht die Welt.

Klaus

Sicher ist es schon, die Uhrzeit bei Files ist nicht sehr wichtig. Eben nur unschoen und laestig, so wie das gekappte Executable-Feature.

Offensichtlich ist hier gar nichts.

Ob das eventuell damit zusammen hängen könnte, daß du mit deinen Kunden nicht per SMB-Protokoll kommunizierst?

Auf die Gefahr, mich zu wiederholen: sauber designte Netzprotokolle übertragen Timestamps in UTC und dann klappt Kommunikation auch über mehrere Zeitzonen hinweg. Windows speichert Timestamps anscheinend (so lese ich das aus Jörgs Posting) in der jeweiligen localtime, was

a) total bescheuert ist b) die Timestamps deiner Files kaputt macht, wenn du die Zeitzone wechselst und c) offensichtlich zu Problemen mit Samba (genauer gesagt: bei der Übertragung von Timestamps per SMB-Protokoll) führt.

Guckstu zum Beispiel hier:

Vermutlich waren vor deiner Umstellung Samba und Windows auf die gleiche Zeitzone gestellt und sind es jetzt nicht mehr.

Vermutlich greifst du auf den "Filebereich" (was immer du damit meinst) auch mit einem nicht-kaputten Protokoll zu, z.B. FTP.

Es ist ja auch nicht so, daß es keine Netzwerk-Filesystem-Protokolle gäbe, die Timestamps korrekt handhaben. NFS z.B. hat zwar ein paar häßliche Macken, aber Timestamps kann es. Dummerweise kann Windoze zumindest im Auslieferungszustand kein NFS.

Und nochmal muß ich mich wiederholen: natürlich ist Microsoft zu sich selber kompatibel und gibt sich andererseits anscheinend extra Mühe, zum Rest der Welt inkompatibel zu sein [1]. Es ist Ansichtssache, auf wessen Seite man hier den Fehler sieht. Meine Meinung kennst du.

Du hast anscheinend das Wort "vielleicht" überlesen.

In your face! Es gibt Millionen unixoide Rechner im Internet und die können alle Files austauschen, ohne daß dabei Timestamps kaputt gehen. Dann kommt Windoze mit dem SMB-Protokoll dazu und auf einmal gibt es Probleme, die vorher nicht da waren.

XL

Nun ja, fuer mich ist die ganze Computerei nur ein Werkzeug, von dem ich moechte dass es einfach funktioniert. Und das tut Sambalein derzeit nicht :-(

Hat es bis letzte Woche aber.

Per Email und per FTP.

Das wiederum ist Geschmackssache. Ich mag's eben.

Ich wechsle die nie, ausser an der Armbanduhr. Pacific Standard Time rulez ...

Ja, aber: Warum mit Samba und z.B. nicht mit Ubuntu? Ich habe Files mit Gimp (unter Ubuntu in einer Virtual Machine) angetatzt und keine solchen Probleme gehabt.

Dann muss es kleine Elfen in dem Kasten geben, die da nachts dran geschraubt haben :-)

Ja, mit FTP.

Sorry, mea culpa.

Ok, aber mit saemtlichen meiner Kunden habe ich keine Probleme. Und die sitzen ziemlich ueber den Globus verteilt (benutzen geschaeftlich allerdings alle Windows).

Joerg schrieb:

Auf dem Lumpenzeugs ist meist eine völlig fossile Sambaversion drauf. In den c't Tests geht der Krempel regelmäßig baden.

Butzo

Tja, kann man nix machen. Ist ein Western Digital MyBook World mit Ethernet. Nur warum klappt das in fossilen Versionen nicht, wenn Linux doch schon immer alles viel besser koennen sollte? Laenger als drei Jahre ist das Ding m.W. noch nicht am Markt.

Jedenfalls wird die naechste Kiste Windows haben, da gibt's nix.

Ja. Eben.

Was ist eigentlich eine rhetorische Frage?

Du hast nicht nachgedacht. Im Normalfall kann es dir ja egal sein, wie dein System Timestamps abspeichert, vorausgesetzt es zeigt sie richtig an. Aber jetzt stell dir mal vor, du nimmst deine USB-Platte mit zu einem Kunden in einer anderen Zeitzone und steckst sie da an seinen Rechner. Schwupps sind alle deine Timestamps daneben. Und wenn du da jetzt Files änderst, stimmt der Timestamp zuhause dann auch wieder nicht.

Unter hinreichend ungünstigen Fällen entscheidet dann dein "synchro- nisiere externe Platte mit Rechner" Programm zu Hause falsch herum, welche Datei denn jetzt die neuere ist.

Mit UTC-Timestamps löst sich das Problem in Wohlgefallen auf. Eine vor einer Stunde geänderte Datei wird immer als vor einer Stunde geändert angezeigt. Auch wenn das - je nach eingestellter Zeitzone - eine andere absolute Uhrzeit ist.

Tja. Weiter oben hast du selber geschrieben, daß du was geändert hast und es jetzt nicht mehr geht. Deine Timestamps sind hier also nicht das einzige inkonsistente ...

Weil Ubuntu die Files ja in seinem eigenen Filesystem (und selbstredend mit UTC-Timestamps) abspeichert. Das Problem ist das Netzwerkprotokoll zwischen Samba und deinem Windoze.

Und verwenden für die Kommunikation Protokolle aus der UNIX-Welt. Jetzt hör auf, dich blöd zu stellen.

XL

:-)

Das macht nichts. Dann zeigt sie mir eben an, zu welcher Ortszeit ich dort an den Files gearbeitet habe. Wenn der Kunde eine Kopie braucht, moechte er das manchmal sogar so (dann muss ich meine PC Uhr umstellen falls an meinem Rechner).

Sync benutze ich grundsaetzlich nicht. Das geht hier strikt nach Check Liste.

Geaendert? Samba hat was geaendert, nicht ich.

Mir geht es nur darum, dass es wieder so wie frueher laeuft. Was es seit letzter Wochen aus dem blauem heraus nicht mehr tut, und zwar nur mit dem Samba Kasten gibt es den Aerger. Aber da kann man eventuell nichts dran machen.

Ich finde bei einer Datumsangabe eher die Relation zu einer anderen Datumsangabe, sei es die aktuelle Zeit oder welche auch immer, wichtig; also gerade ohne Rechnerei, was in welcher Zeitzone geschehen ist. Aber das ist sicherliche auch Geschmackssache.

Das Problem ist, dass du dieses Speicherformat an dieser Stelle als Praktisch ansiehst, es aber an vielen anderen Stellen zu Problemen führen kann, wenn die Übertragungsprotokolle nicht wasserdicht sind. Und leider ist MS eben nicht für Kompatibilität mit dem Rest der Welt bekannt.

Siehe oben. Ist eben ein Wuergaround.

Grüße Alex

Es bahnt sich ein anderer Wuergaround an, muss aber erst ein Projekt fertigstellen und aufliefern, dann versuche ich das: Habe gestern mal eine Directory mit Files probeweise komplett auf einen XP Rechner gepackt, auf dem Linux Server geloescht, dann zurueck auf den Linux Server -> Uhrzeit stimmte wieder. Erinnert mich irgendwie an alte Fernseher, wo ein beherzter Schlag gegen eine bestimmte Stelle des Gehaeuses manchen Fehler "behob".