SBLAN2: Dateidatum und -uhrzeit beim Kopieren verändert

[George023]

Hallo zusammen,

ich habe eben mal wieder ein paar neue Fotos von meinem Kartenleser im PC direkt auf mein SBLAN2 kopiert.
Dabei wurden sowohl Uhrzeit als auch Datum der einzelnen Dateien auf die "lokale Zeit" der SBLAN2 geändert. Da die Box mal wieder nachging, waren das drei Stunden vor dem Kopiervorgang. Als ich dann die Uhrzeit der Box manuell synchronisiert hatte, erhielten die nächten Dateien die aktuelle Zeit.
Ich weiss, dass bis vor kurzem die Zeitinformationen von Dateien beim Kopieren auf die Box nicht verändert wurden. Das habe ich auch bei Dateien von letztem Monat nochmals nachgesehen.

Hat jemand eine Erklärung für dieses merkwürdige Verhalten?

Vielen Dank für die Hilfe
George

[lochness]

Ich weiß, es nützt Dir nichts, aber ich habe gestern was ähnliches gesehen. Ich bin aber nicht draus schlau geworden, vielleicht kommen wir zusammen weiter.
Alle alten Dateien sind noch ok
Ich bin schon am überlegen, was es sein könnte.
Ich habe nichts am AMS geändert. Alles Standard. Ich habe FAT32 Geräte angeschlossen. Ich habe das Gerät auf Sommerzeit gestellt und die Zeit synchronisiert. Mehr hatte ich in letzter Zeit nicht geändert.
Danach habe ich die USB-Geräte entfernt und die Sommerzeit zurückgestellt, die Zeit neu eingestellt und das Gerät gebootet. Das hat bei mir nichts geholfen.
Das Verhalten beim Kopieren ist aber merkwürdig. Mache ich das mit Textdateien und kopiere eine nach der anderen und aktualisiere den Bildschirm, so hat immer die zuletzt kopierte das aktuelle Datum, die älteren sind ok. Also, wenn ich eine neue reinkopiere und aktualisiere, bekommt die vorher kopierte das richtige Datum. Wenn ich den Ordner verlasse und wieder zurückkehre, sind alle Textdateien richtig (auch die letzte). Bei anderen Dateien konnte ich das so nicht beobachten.
Ich wollte das mal aufzeichnen, vielleicht sieht man auf dem LAN was.

Meinst Du, es ist so seit der Sommerzeit?

[George023]

Das mit der Sommerzeit ist tatsächlich die letzte mir bewusste Änderung. Seitdem habe ich auch keine Fotos mehr kopiert. Könnte also sehr gut sein.
Ich schaue auch noch mal, ob ich noch was anderes finde. Ansonsten wäre das wohl der nächste Call an den Support.

Bin auf jeden Fall insofern beruhigt, dass ich zumindest keine Option übersehen habe. Oder ich habe sie wenigstens nicht alleine übersehen

Gruß
George

[George023]

Hallo zusammen,

eben kam eine Antwort vom FSC Support, weil ich kurz vorher nochmals nach einem Status zu dem Problem gefragt hatte.

laut unser Entwicklung ist dieses Phänomen normal, da diese Festplatte ein Linux-Filesystem besitzt. Leider gibt es keine weitere Lösung von unser Entwicklung für dieses Problem.

Mit freundlichen Gruessen

Hier meine Antwort.

Guten Tag,
ich kann diese Information leider nicht bestätigen.
Bis vor wenigen Wochen (meine Vermutung: Umstellung auf Sommerzeit) war das Verhalten der SBLAN2 bzgl. des Dateidatums einwandfrei. Beim Kopieren blieb das Dateidatum unverändert.
Erst seit dieser Zeit wird das Dateidatum beim Kopieren verändert.

Dieses Verhalten ist als Fehler einzustufen und ich bitte um umgehende Korrektur bzw. Lösung des Problems.
Mit freundlichem Gruß

Mal gespannt, ob noch eine sinnvolle Antwort kommt. Die erste Antwort vom FSC Support halte ich für eine Unverschämtheit.

Gruß
George

[lochness]

Nun, generell ist es schon so, dass eine Datei unter UNIX/Linux das neue Datum erhält, wenn sie kopiert wird. Im Gegensatz zu Windows. Allerdings sind im SMB/CIFS Protokoll Vorkehrungen getroffen, dass das Datum beibehalten wird. Der Windows PC schickt diese Informationen über das Netz zum SAMBA Server und dieser sollte es dann passend umsetzen.

Aber, dieses Problem ist nicht so ganz trivial. Ich habe jetzt schon einige Zeit geforscht. Es ist so, dass der SAMBA Server das Datum vom PC korrekt bekommt, aber die Operation dann noch nicht ausführt, sondern für den nachfolgenden "Close" der Datei speichert. Das ist grundsätzlich so, weil ansonsten das Datum beim Close sowieso wieder angefasst würde. Nun passiert es aber, dass der Windows PC, während die Datei noch geöffnet ist, die Zeitinformationen abfragt und dann ein zweites Mal setzt. Da diese Daten aus dem Dateisystem geholt werden und die Änderung ja noch gar nicht durchgeführt wurde, bekommt der PC den aktuellen Zeitstempel und setzt ihn dann falsch.

Aus dem Grund tippe ich nun darauf, dass das geänderte Verhalten nicht direkt von dem SBLAN2/AMS ausgeht, sondern ggf. durch einen Patch von Microsoft in Windows Vista und Windows XP reingekommen sein könnte bzw. die Windows PCs plötzlich an der Stelle ein geändertes Verhalten zeigen (z.B. bei Sommerzeit oder Zeitdifferenzen mit dem Server?). Ich habe hier aber einen Linux-basierten SAMBA Server (Version 3.0.24) laufen, der funktionert. Dieser liefert bei der besagten Abfrage das richtige Datum zurück, daher setzt der PC in dem Fall das richtige Datum.

[Nachtrag 12.05.] Ich habe mittlerweile mit einigen PCs getestet.
Windows XP Home funktioniert nicht (drei Rechner)
Windows XP Professional funktioniert (zwei Rechner)
Windows XP Media Center funktioniert nicht (ein Rechner)
Windows Vista funktioniert nicht (ein Rechner)
Kann Zufall sein, je nach installierten Applikationen, klar. Jedenfalls ist der Fehler nicht durch den SBLAN/AMS entstanden, sondern hängt vom Client ab.

[lochness]

Ich denke, wir können die Analyse hier beenden. In Samba 3.0.24 ist das Problem definitiv gelöst. Dort wird auch bei einer geöffneten Datei das Datum im Dateisystem richtig gesetzt, weil es ja abgefragt werden könnte.
Für Source-Code-Leser , das ist die Stelle im alten Code mit dem - schon nicht ganz treffenden - Kommentar (Datei trans2.c):

/*
* This was a setfileinfo on an open file.
* NT does this a lot. It's actually pointless
* setting the time here, as it will be overwritten
* on the next write, so we save the request
* away and will set it on file close. JRA.
*/
...

Richtig ist es hier:

/*
* This was a setfileinfo on an open file.
* NT does this a lot. We also need to
* set the time here, as it can be read by
* FindFirst/FindNext and with the patch for bug #2045
* in smbd/fileio.c it ensures that this timestamp is
* kept sticky even after a write. We save the request
* away and will set it on file close and after a write. JRA.
*/
...

Die Lösung wäre also, entweder diesen kompletten Fix in die ältere SAMBA-Version 3.0.6 zurückzuportieren oder gleich eine aktuelle SAMBA-Version in den AMS/SBLAN2 zu integrieren.

[George023]

Hi Lochnesss,

vielen Dank für die Recherche. Wenn sich den Support wieder anstellt, werde ich mir die Freiheit nehmen Dich zu zitieren. Bin sehr zufrieden zu hören, dass es eine Lösung gibt.
Mich wundert ja immer noch, dass das Problem erst seit relativ kurzer Zeit auftritt. Aber vielleicht kommt der Support ja auch selber drauf...

Gruß
George

[lochness]

Mich wundert ja immer noch, dass das Problem erst seit relativ kurzer Zeit auftritt.

Ich hatte meinen Beitrag oben noch mal bearbeitet. Ich habe heute hier von sieben Rechnern immer noch zwei, mit denen das Problem nicht auftritt. Muss durch eine Änderung von Microsoft reingekommen sein. Ich kann aber nicht sagen, ob Windows selbst oder eine bestimmte Anwendung Schuld ist. Könnte noch der Unterschied zwischen XP Home und XP Prof sein (ist aber unwahrscheinlich, da XP Media Center auf auf XP Prof basiert) oder die Sprache (deutsch oder englisch, die, die gehen, sind englisch bzw. multi-language). Na ja, jedenfalls habe ich hier Rechner, die gehen und welche, die nicht gehen, also kann ich das gut testen.

[George023]

Ich habe heute eine interessante Entdeckung gemacht.
Ich habe aus einem RAR-Archiv mithilfe der Software WinRAR (v3.41) verschiedene Dateien direkt auf ein Netz-Laufwerk auf dem SBLAN2 ausgepackt. Das Datum dieser Dateien ist erhalten geblieben.
Wenn ich allerdings Dateien per Drag-And-Drop ausgepackt habe, wurde das Datum geändert.
Das passt ja dann zu lochness' Information, dass das Problem von einem Windows-Patch o.ä. verursacht wurde. Denn beim "direkten" Auspacken schreibt WinRAR die Dateien selber auf das Netz-Laufwerk. Beim Drag-And-Drop werden die Dateien zuerst in einem temporären Ordner ausgepackt und dann veschoben (über ein Windows-Copy).
Man scheint also nicht die ganze Schuld auf FSC schieben zu können...

Ich werde demnächst noch einen Versuch über die Kommando-Zeile starten. Mal sehen, wie das Ergabnis dann aussieht.

Gruß
George

[lochness]

Ich werde demnächst noch einen Versuch über die Kommando-Zeile starten. Mal sehen, wie das Ergabnis dann aussieht.

Damit wird das Datum auch verstellt. Auch mit einem Programm wie z.B. FileSync, wenn man damit kopiert. Programme, die erst kopieren, dann die Datei schliessen und dann das Datum setzen, funktionieren aber. Und, auch Programme, die nur das Datum setzen.
Ich denke, es hängt einfach davon ab, wie das Programm arbeitet, in welcher Reihenfolge und welche Windows-APIs es benutzt.

[mega]

Das mit der Zeit ist ein klarer Fehler des SBLAN2.

Mein Flepo F6200 (baugleich u.a. Allnet all6200) hat das Problem nicht. Zusätzlich geht bei dem Flepo auch die Uhr dauerhaft richtig. Der SBLAN2 schafft über ne Stunde Abweichung im Monat und NTP geht erst nicht.

Ich werde das Teil wieder verkaufen und dafür kommt dann noch ein zum F6200 baugleicher von Longshine 8220, der noch nen Webserver drin hat.

Hat einer ne Ahnung, wie es beim all6250 mit der Zeit ist? Der ist baugleich zum SBLAN2

[lochness]

Das mit der Zeit ist ein klarer Fehler des SBLAN2.

Klar ... Ist ein Fehler des SAMBA Servers.

Mein Flepo F6200 (baugleich u.a. Allnet all6200) hat das Problem nicht. Zusätzlich geht bei dem Flepo auch die Uhr dauerhaft richtig. Der SBLAN2 schafft über ne Stunde Abweichung im Monat und NTP geht erst nicht.

NTP geht schon, aber nur manuell und nicht regelmäßig.

Ich werde das Teil wieder verkaufen und dafür kommt dann noch ein zum F6200 baugleicher von Longshine 8220, der noch nen Webserver drin hat.

Der SBLAN2 hat auch einen Webserver

Hat einer ne Ahnung, wie es beim all6250 mit der Zeit ist? Der ist baugleich zum SBLAN2

Wenn er baugleich ist, hat er das gleiche Problem, sonst wäre er ja nur bau-ähnlich . Aber, es gibt zumindest bei Longshine schon eine Firmware 2.x mit einem Fix für NTP und vielleicht auch für Samba (?).

[mega]

NTP geht schon, aber nur manuell und nicht regelmäßig.

Der SBLAN2 hat auch einen Webserver

Wenn er baugleich ist, hat er das gleiche Problem, sonst wäre er ja nur bau-ähnlich .

1. Bei mir wollte der NTP nicht, nur lokale Zeit. Und wenn die nur von Hand geht, ist doch doof.

2. Wenn das SBLAN2 nur für den Webserver da ist und ich für alles andere ein anderes Gerät habe, macht das auch nicht wirklich Sinn. So ne Reihe NAS-Geräte Nebeneinander mag zwar nett aussehen, kostet aber und ne größere Fritz!Box als WDS-Repeater wo die dran sind kostet auch. und in nem Lagerraum ist es eigentlich egal, wie das ganze aussieht.

Das mit der falschen Datei-Zeit ist doch einfach doof.
Dazu kommt noch diese grottige User-Verwaltung. Windows bietet nicht an, den Zugang zu speichern. Alles offen lassen ist auch keine Lösung, weil man es dann von außen nicht mehr als FTP benutzen kann. Beim Flepo 6200 muss man zwar die Benutzernamen genau gleich denen des verwendeten Windows setzten, weil Windows dort das freie eingeben nicht anbietet, aber wenigstens klappt es.

3. Die Hardware ist fast gleich, die Software aber nicht. Wobei auch die HW nur Ähnlich sind. Das Gehäuse ist an den Seiten so komisch krumm eingebeult bei Allnet.

Wieso gibts eigentlich bei Longshine Sachen, die es bei Flepo und Allnet nicht gibt? Und bei FSC andere Bugs? Liefert der Hersteller da ein Grundgerüst an Software-System, was die Vertreiber dann selber ausbauen können/müssen?

[lochness]

1. Bei mir wollte der NTP nicht, nur lokale Zeit. Und wenn die nur von Hand geht, ist doch doof.

Wie gesagt, bei Longshine geht das jetzt, laut Longshine Forum, schon.

2. Wenn das SBLAN2 nur für den Webserver da ist und ich für alles andere ein anderes Gerät habe, macht das auch nicht wirklich Sinn. So ne Reihe NAS-Geräte Nebeneinander mag zwar nett aussehen, kostet aber und ne größere Fritz!Box als WDS-Repeater wo die dran sind kostet auch. und in nem Lagerraum ist es eigentlich egal, wie das ganze aussieht.

Die Argumentation kann ich nicht nachvollziehen, der SBLAN2 kann ja eigentlich alles.

Das mit der falschen Datei-Zeit ist doch einfach doof.

Es gibt zwei Probleme mit der Zeit, einmal dass sie komplett nicht gesetzt wird und dann das Nachgehen der Uhr.

Dazu kommt noch diese grottige User-Verwaltung. Windows bietet nicht an, den Zugang zu speichern.

Wenn das an dem NAS liegt, müsste man es mal analysieren. Das schaue ich mir bei Gelegenheit mal an.

[mega]

Die Argumentation kann ich nicht nachvollziehen, der SBLAN2 kann ja eigentlich alles.

Aber nix richtig: Uhr, Datei-Zeit, User-Verwaltung.
Unnötige Einschränkungen: Usernamen nur klein, Share-Namen dürfen kein - haben.

Bleibt also als wirklich verwendbar nur der Web-Server.