Zeitstempel ändert sich nicht

J

Jenny_L1

Jungspund
Systembeschreibung:

Modell: ReadyNAS NV+ [X-RAID]
Firmware: RAIDiator 4.1.6 [1.00a043]
Speicher: 256 MB [2.5-3-3-7]

Samba-Version: 3.0.34

Problembeschreibung:

Kann mit einem XP-Client auf einer NAS (über SAMBA) per Programm in eine Datei schreiben,
den Inhalt verändern und trotzdem bleibt der Zeitstempel unverändert.
Weder das Änderungsdatum noch der letzte Zugriff werden aktualisiert.
Wie gibt es das?
 
timestamp problem with specific file size

Systembeschreibung:

Modell: ReadyNAS NV+ [X-RAID]
Firmware: RAIDiator 4.1.6 [1.00a043]
Speicher: 256 MB [2.5-3-3-7]

Samba-Version: 3.0.34

Problembeschreibung:

Kann mit einem XP-Client auf einer NAS (über SAMBA) per Programm in eine Datei schreiben,
den Inhalt verändern und trotzdem bleibt der Zeitstempel unverändert.
Weder das Änderungsdatum noch der letzte Zugriff werden aktualisiert.
Wie gibt es das?

************
Konnte den timestamp-Fehler jetzt endlich eingrenzen:

Egal mit welchem User ich eine Datei anlege, der timestamp wird auf meiner NAS bei einer kleinen Textdatei nur richtig aktualisiert,
wenn sie maximal 236 Byte hat.

Ist mir völlig unverständlich wie es so was geben kann...

Muss eine neuere Samba-Version auf die ReadyNAS NV+???
 
Ich glaube nicht, dass es an der Samba-Version liegt. Für das Setzen der Zugriffs- und Änderungszeitstempel ist der Kernel, speziell der Dateisystem-Treiber zuständig. Ggf. verschafft ein Kernel-Update also Abhilfe. Ich höre allerdings von einem solchen Fehler das erste Mal.
 
Kernel upgrade ist wohl notwendig, aber

Ich glaube nicht, dass es an der Samba-Version liegt. Für das Setzen der Zugriffs- und Änderungszeitstempel ist der Kernel, speziell der Dateisystem-Treiber zuständig. Ggf. verschafft ein Kernel-Update also Abhilfe. Ich höre allerdings von einem solchen Fehler das erste Mal.

ein Kernel upgrade ist wohl notwendig (exploit Möglichkeit bei 2.6.17.8), aber
gibt es vielleicht auch Einstellungsmöglichkeiten entsprechend atime / noatime,
die leider nur die Speicherung der Zeit des letzten Zugriffs beeinflussen auch für die Speicherung der Zeit der letzten Dateiänderung?
 
Ich wüsste nicht, dass es Mount-Flags für die Änderungsdaten gibt, ausser eben für die Zugriffszeit. Allerdings hab ich mir vorhin in einer Diskussion über Journaled Dateisysteme sagen lassen, dass nicht korrekte Zeitstempel auch durch ein nicht-synchrones Dateisystem-Journal entstehen können. Wenn du also ein FS wie Ext3, ReiserFS o.ä. einsetzt, solltest du ggf. mal einen vollständigen Dateisystem-Check durchlaufen lassen.
 
magische 236 byte

Ich wüsste nicht, dass es Mount-Flags für die Änderungsdaten gibt, ausser eben für die Zugriffszeit. Allerdings hab ich mir vorhin in einer Diskussion über Journaled Dateisysteme sagen lassen, dass nicht korrekte Zeitstempel auch durch ein nicht-synchrones Dateisystem-Journal entstehen können. Wenn du also ein FS wie Ext3, ReiserFS o.ä. einsetzt, solltest du ggf. mal einen vollständigen Dateisystem-Check durchlaufen lassen.

Danke für den Tip, das werde ich heute abend auf jeden Fall mal machen,
aber
die Sache wird immer verrückter.

Nun bin ich wieder ein Stück weitergekommen.
Ich kann nun auch den Inhalt von Dateien die größer sind als 236 Bytes so ändern,
dass der Timestamp "geändert am" - last modified date/time - sofort aktuell zurückgeschrieben wird, und zwar indem ich die Variablen, die ich verändere nicht in einer Field-Anweisung puffere,
sondern als String zurückschreibe.
Merkwürdigerweise stoße ich aber auch hier auf die Grenze von 236 Bytes bei der Variablenlänge.
Sobald ich meine Stringvariable länger als 236 Zeichen definiere findet trotz Dateiänderung wieder keine Änderung des Timestamp statt.

Es ist wirklich zum verrückt werden!


Code:
DIM x AS STRING * 944
OPEN "nummer1.tst" FOR RANDOM AS 1 LEN = 944
LOCK 1
GET 1, 1, x
x = "123456" + MID$(x, 7) 'oder nur x="123456"
PUT 1, 1, x
UNLOCK 1
CLOSE 1
END

Der Dateiinhalt ändert sich an Stelle 1-6 auf "123456", aber der Zeitstempel ist immer noch der alte!

Code:
DIM x AS STRING * 236 '** (oder kleiner) **
OPEN "nummer1.tst" FOR RANDOM AS 1 LEN = 944
LOCK 1
GET 1, 1, x
x = "999999" + MID$(x, 7) 'oder nur x="999999"
PUT 1, 1, x
UNLOCK 1
CLOSE 1
END
Der Dateiinhalt ändert sich an Stelle 1-6 auf "999999", und hier ändert sich auch der Zeitstempel auf die aktuelle Zeit!!!
 
Zuletzt bearbeitet:
keine änderung nach fsck -f

Sowohl ein Festplattencheck über die frontview Weboberfläche als auch
ein fsck -f über die Console brachte keine Änderung

Ausschnitt aus dmesg.log nach Check über Weboberfläche (keine Fehler gefunden):
Code:
X_RAID_START
startstop XRAID command = start, flash_cache=0
X_RAID clean shutdown indicator: 0x0.
0 4 4 4 4 0 0 0
0 1 1 1
1 0 1 1
1 1 0 1
1 1 1 0
Update time for sb 1 = 4a1c323f.
Update time for sb 2 = 4a1c323f.
Update time for sb 3 = 4a1c323f.
Update time for sb 4 = 4a1c323f.
recent_ID = 1, select_ID=1, most_ID=4 right_mac=4
Selected sb 1, ctime=4a1c323f, id=a201ec53.
Use this image: 1

VERSION/ID : SB=(V:0.1.0) ID=<a201ec53.00000000.00000000.00000000> CT:4a1c323f
RAID_INFO : DISKS(TOTAL:4 RAID:4 PARITY:1 ONL:4 WRK:4 FAILED:0 SPARE:0 BASE:0)
SZ:0976752688 UT:00000000 STATE:0 LUNS:2 EXTCMD:1 LSZ:0976752686
LOGICAL_DRIVE : 0: B:0000000002 E:0004096000 R:1 O:1 I:1:000000000 DM:f
LOGICAL_DRIVE : 1: B:0004096002 E:0972656686 R:4 O:1 I:1:000000000 DM:f
PHYSICAL_DRIVE: 0: DISK<N:0/1,hdc(22,0),ID:0,PT:1,SZ:0976752688,ST: B:online>
PHYSICAL_DRIVE: 1: DISK<N:1/2,hde(33,0),ID:1,PT:1,SZ:0976752688,ST:P :online>
PHYSICAL_DRIVE: 2: DISK<N:2/3,hdg(34,0),ID:2,PT:1,SZ:0976752688,ST: :online>
PHYSICAL_DRIVE: 3: DISK<N:3/4,hdi(56,0),ID:3,PT:1,SZ:0976752688,ST: :online>
CURRENT_DRIVE : DISK<N:0/1,XXX(22,0),ID:0,PT:1,SZ:0976752688,ST: B:online>
Need to do drives searching.
Find p d at 1, chn 1
Total=4; raid=4; ready=0; work=4; failed=0
Check degraded mode, start_pos=1
No drive missing, X_RAID run in opt mode.
Change X_RAID running mode from 0 to 1
Update backup SB.
X_RAID: recovery thread got woken up ...
New = 1, source drives = f, current/active=4/4
hdc: hdc1 hdc2 hdc3 < hdc5 >
hde: unknown partition table
hdg: hdg1 hdg2 hdg3 < hdg5 >
hdi: hdi1 hdi2 hdi3 < hdi5 >
chn=2, statu/LP_S=0x(d0/d050)29, 32
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on hdc1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.

Welche Info könnte helfen dem Fehler auf die Schliche zu kommen bzw.
an welches Forum könnte ich mich sonst wenden?
 
Zuletzt bearbeitet von einem Moderator:
Ggf. könnte dir die Kernel-Mailingliste weiterhelfen.
 
timestamp fehlerhaft mit oplocks?

zu diesem thema hab ich dort nichts gefunden!

verwende cifs, Zugriff von einer XP Workstation im DOS-Fenster per Samba auf die ReadyNAS NV+, oplocks = 1 (od. fake oplocks = 1)
Die Datei wird lesend und schreibend geöffnet.

alte qb4.5 Programme, die so bezüglich der Aktualisierung des Zeitstempels nicht mehr funktionieren:
Variante A funktioniert nur, wenn die Datei max. 236 Byte groß ist, ab 237 Byte bleibt der Zeitstempel unverändert, obwohl sich der Dateiinhalt ändert!
D. h. mit oplocks wird nicht richtig synchronisiert bzw. die Synchronisation ist irgendwie von der Größe der Datei bzw. der Variablenpuffer abhängig.

prinzipieller Ablauf:
Variante A)
OPEN "nummer1.tst" FOR RANDOM AS 1 LEN = 118 ' Datei read write für Direktzugriff öffnen
FIELD 1, 6 AS nummer$ 'Platz für string-Variable in Direktzugriffs-Dateipuffer zuweisen
LOCK 1, 1 ' Satz sperren
GET 1, 1 'Satz holen - field-Variable erhält Dateiinhalt des 1. Satzes, Stelle 1-6
LSET nummer$ = "123456" 'Variable neu belegen
PUT 1, 1 'Variable in Datei zurückschreiben
UNLOCK 1, 1 'Satz entsperren
CLOSE 1 'Datei schließen
end

Variante B)
Zeitstempel wird weder mit noch ohne oplocks aktualisiert!!!

so wird der Zeitstempel auch nicht geändert
DIM x AS STRING * 944 'variable als string-Variable vordefinieren
OPEN "nummer1.tst" FOR RANDOM AS 1 LEN = 944 '' Datei read write für Direktzugriff öffnen
LOCK 1 'sperren Datei
GET 1, 1, x 'Variable mit Dateiinhalt füllen
x = "123456" + MID$(x, 7) 'oder nur x="123456"
PUT 1, 1, x 'Variable in Datei zurückschreiben
UNLOCK 1 ' Datei entsperren
CLOSE 1 'Datei schließen
END

Variante C)
so wird der Zeitstempel auch mit oplocks aktualisiert:

DIM x AS STRING * 236 '** (oder kleiner) **
OPEN "nummer1.tst" FOR RANDOM AS 1 LEN = 236
LOCK 1
GET 1, 1, x
x = "999999" + MID$(x, 7) 'oder nur x="999999"
PUT 1, 1, x
UNLOCK 1
CLOSE 1
END

FAZIT:
Nur wenn die Datei maximal 236 byte groß ist bzw. die Variablenlänge maximal 236 Byte groß ist wird der Zeitstempel aktualisiert, wird richtig synchronisiert, wenn (fake) oplock = 1 gesetzt ist.

Ist das nicht sehr merkwürdig und kann das jemand nachprüfen?
Hat noch jemand Qbasic(oder QB4.5) zur Verfügung und kann meinen Code auf der ReadyNAS testen?

Muss nämlich noch alte Programme betreuen und da stecken fast 1 MIO Zeilen Code dahinter, die will ich nicht alle durchforsten und umschreiben müssen.
 
Zuletzt bearbeitet:
QBasic Fehler schließe ich aus

Fehler in QB4.5 schließe ich aus, da dieselben Programme jahrelang fehlerfrei auf Novell Netware 3.12 gelaufen sind ohne irgendwelche Zeitstempelprobleme oder Updateprobleme!

Lokal funktioniert natürlich alles!

Laufwerksverknüpfungen auf der NAS existieren über "net use"
 
Problem mit Zeitstempel gelöst!

der NAS Lieferant NETGEAR hat eine neue firmware rausgebracht.
Damit ist das Problem mit dem Zeitstempel erledigt.
Das uralte QB4.5 war also nicht Schuld!
 
leider leider zu früh gefreut

wenn ich die Dateigröße ändere, also z. B. Datensätze zufüge ändert sich auch der Zeitstempel (letzter Zugriff, Änderungszeit)
wenn ich aber bei Dateien größer 236 Byte den Inhalt durch Direktzugriff per Programm verändere
(nicht mit einem Editor, da der ja den Inhalt temporär kopiert und komplett zurückschreibt)
bleibt der Zeitstempel (timestamp) doch unverändert (sowohl letzter zugriff wie auch Änderungszeit)!

Traurig, aber wahr!
 

Ähnliche Themen

Rollei Mini Wifi Camcorder

XFCE freezes at startup

Datei kann nicht kopiert werden: Der angegebene Netzwerkname ist nicht mehr verfügbar

[openSuse10.2] SATA mal wieder...

Meine Distri spielt verrückt !

Zurück
Oben