Probleme mit FAT32-NTFS

[Hinnerk V]

habe einen fileserver (windows2000) mit zwei FAT32-HDs. nach der
umstellung zur sommerzeit sind die Zeitstempel der Dateien jetzt eine
stunde hinter dem sicherungslaufwerk zurück. wenn ich so eine sicherung
(auf portabler NTFS-HD) machen will, die das datum der datei
berücksichtigt, will des backup-programm alle dateien kopieren (>150GB).
was kann ich da tun.
FAT32 in NTFS konvertieren?
- ist das sicher? Datenverlust?
- mit was für einem programm? - oder einfach convert.exe

gibt es ansonsten noch lösungen?

[Norbert Hahn]

Post by Hinnerk V
habe einen fileserver (windows2000) mit zwei FAT32-HDs. nach der
umstellung zur sommerzeit sind die Zeitstempel der Dateien jetzt eine
stunde hinter dem sicherungslaufwerk zurück.

Dann hat Dein Sicherungsprogramm ein Problem!
Ich kann z.B. bei TotalCommander beim Dateivergleich einstellen, dass
exakt eine Stunde Zeitdifferenz zu ignorieren ist. Das Problem kam
irgendwann mal mit NTFS oder Windows NT auf die Welt. Programme, die
jünger als 10 Jahre sind, sollten damit umgehen können.

Norbert

[Andreas Randolf]

Hallo,

Das Problem kam irgendwann mal mit NTFS oder Windows NT
auf die Welt.

Schon viel früher. Das CD-Dateisystem ISO9660 hat eine
Zeitzonenangabe. Die wird aber nicht von jedem Betriebssystem
berücksichtigt. Steck mal eine CD in einen Windows 95 und
einen NT-Computer und vergleiche die Zeitstempel.

Praxisrelevant ist das Problem z.B. wenn man in einer anderen
Zeitzone seine Digitalfoto-Speicherkarte auf CD brennt
und dann zu Hause ausliest.

[Christian Franke]

Post by Andreas Randolf
Hallo,

Das Problem kam irgendwann mal mit NTFS oder Windows NT
auf die Welt.

Schon viel früher. Das CD-Dateisystem ISO9660 hat eine
Zeitzonenangabe. Die wird aber nicht von jedem Betriebssystem
berücksichtigt. Steck mal eine CD in einen Windows 95 und
einen NT-Computer und vergleiche die Zeitstempel.

NTFS speichert die Zeiten in UTC, FAT in Lokalzeit.
Die Win32 Funktionen zur Umrechnung (z.B. FileTimeToLocalFileTime) sind
spätestens seit NT4 fehlerhaft:
Während der Sommerzeit werden bei der Umrechung alle Zeiten um 1 Stunde
verschoben, auch die aus der Winterzeit. Umgekehrt ebenso.
Im Explorer werden daher alle Zeiten aus der jeweils anderen
Sommer/Winterzeitzone um eine Stunde verschoben angezeigt.
Das gilt für NTFS, bei FAT gleicht sich der Fehler aus.
Für eine Korrektur in einem Kopierprogramm muss also das
zugrundeliegende Dateisystem berücksichtigt werden.

Alle Windows Versionen bis Vista RC1 sind hier "rückwärtskompatibel".
Ob der Fehler in Vista endlich beseitigt ist, weiss ich nicht.

Post by Andreas Randolf
Praxisrelevant ist das Problem z.B. wenn man in einer anderen
Zeitzone seine Digitalfoto-Speicherkarte auf CD brennt
und dann zu Hause ausliest.

In dem Fall kann man glücklicherweise mit entsprechenden Tools den
Zeitstempel wieder auf den im EXIF gespeicherten zurücksetzen.

Christian

[Andreas Randolf]

Hallo,

Post by Christian Franke
NTFS speichert die Zeiten in UTC, FAT in Lokalzeit.

ISO9660 speichert ebenfalls Lokalzeit, gibt aber die
Zeitzone an.

Es ist auch ein Unterschied, ob man sagen will "Die
Datei wurde um 8:32 Lokalzeit gebrannt" oder "Als
die CD gebrannt wurde, war es in Deutschland 8:32 Uhr."

Post by Christian Franke
Die Win32 Funktionen zur Umrechnung (z.B. FileTimeToLocalFileTime)
Während der Sommerzeit werden bei der Umrechung alle Zeiten um 1 Stunde
verschoben, auch die aus der Winterzeit. Umgekehrt ebenso.

Ja, ziemlich nervig. Ich habe bei einigen Rechner die automatische
Sommer-/Winterzeitumstellung abgeschaltet (weil ich dort
ständig Images zurückfahre).

Post by Christian Franke

Post by Andreas Randolf
Praxisrelevant ist das Problem z.B. wenn man in einer anderen
Zeitzone seine Digitalfoto-Speicherkarte auf CD brennt
und dann zu Hause ausliest.

In dem Fall kann man glücklicherweise mit entsprechenden
Tools den Zeitstempel wieder auf den im EXIF gespeicherten
zurücksetzen.

Was gibt es da für den Mac?

[Marcel Müller]

Post by Christian Franke
NTFS speichert die Zeiten in UTC, FAT in Lokalzeit.
Die Win32 Funktionen zur Umrechnung (z.B. FileTimeToLocalFileTime) sind

Im ernst?
Das würde einiges erklären. Ich habe bei der Remotesynchronisation über
ZIP-Files und eine Index-Datei es auch nie ohne 3602s Toleranz
hinbekommen zwischen verschiedenen Betriebssystemen (damals meist Win2k
vs. OS/2) Dateien inkrementell auszutauschen. Rund um die
Sommerzeitumschaltung gab es immer Ärger.

Post by Christian Franke
Alle Windows Versionen bis Vista RC1 sind hier "rückwärtskompatibel".
Ob der Fehler in Vista endlich beseitigt ist, weiss ich nicht.

Mich wundert allerdings, dass NT4 nicht betroffen sein soll. Hat es die
Zeiten im NTFS noch als Localtime gespeichert?

Die Sache ist nämlich keineswegs trivial. Es ist dazu erforderlich, die
Sommerzeitregel von dem Jahr zu kennen, in dem der Zeitstempel liegt.
Außerdem ist die Abbildung, wenn man es richtig macht, bei Verlust des
DST-Flags nicht mehr eineindeutig. Das könnte einige Programme bei 24/7
laufenden Maschinen schon mächtig aus dem Tritt werfen, wenn der
Zeitstempel nach einem Umrechnungszyklus sich selbst nicht mehr gleicht.
Möglicherweise war auch genau das die Motivation es so zu belassen. Es
wird einfach gnadenlos nach der aktuellen Zeitzone umgerechnet, nicht
nach der des Zeitstempels. Letztere ist ja genau genommen auch verloren,
da NTFS sie gar nicht speichert. Die Datei könnte ja aus Korea kommen.
Letztlich steckt in der Rekonstruktion der Zeitzone also immer eine
gewisse Willkür.

Programme, die Zeitstempel in Lokaler Zeit mit relationalen Operatoren
vergleichen, gehören sowieso auf den Mond geschossen. Direkt neben
denen, die Preise als Float speichern wäre noch Platz. Nur entledigte
man sich auf die Tour wahrscheinlich gleich 70% aller
Datenbankanwendungen. Und 100 Mio. Fliegen können bekanntlich nicht
irren: Sch*** schmeckt!


Marcel

[Christian Franke]

Post by Marcel Müller

Post by Christian Franke
NTFS speichert die Zeiten in UTC, FAT in Lokalzeit.
Die Win32 Funktionen zur Umrechnung (z.B. FileTimeToLocalFileTime)

Im ernst?

Ja - ich konnte es erst auch nicht glauben.

http://www.codeproject.com/datetime/dstbugs.asp

Post by Marcel Müller
...
Mich wundert allerdings, dass NT4 nicht betroffen sein soll. Hat es die
Zeiten im NTFS noch als Localtime gespeichert?

Nein. Gemeint war "seit NT4 einschließlich ..." ;-)

Der Fehler existiert vermutlich, seit es Win32 gibt (NT 3.5, Win95).
http://support.microsoft.com/kb/158588/en

Bei 9x/ME bleibt der Fehler meistens verborgen, da NTFS fehlt.
Bei der FAT wird dadurch UTC falsch ausgegeben.
Die Funktion stat() aus der MS C-Runtime korrigiert das, das führt aber
wiederum zu falscher UTC bei NTFS.
Win32 API und C-Runtime verhalten sich also genau entgegengesetzt, was
für zusätzliche Verwirrung sorgt.

Post by Marcel Müller
...
Letztlich steckt in der Rekonstruktion der Zeitzone also immer eine
gewisse Willkür.

Es soll lediglich UTC in die eingestellte Zeitzone umgerechnet werden.
Und das bekommt Win32 nicht auf die Reihe.

Gruss

Christian

[Norbert Hahn]

Post by Christian Franke
Der Fehler existiert vermutlich, seit es Win32 gibt (NT 3.5, Win95).
http://support.microsoft.com/kb/158588/en

Der Artikel hat das Datum "Last Review: February 26, 2007", Revision
2.3.
Und weiter unten findet man:
"...an additional hour is added to GMT during Daylight Saving Time
(the first Sunday in April through the last Sunday in October)."

Wenn ich mich richtig erinnere, wurde aber schon am letzten Sonntag
auf Sommerzeit umgestellt. Ich werde wohl meine Server nach Arizona
umziehen...

Norbert

[Hinnerk V]

Am Wed, 28 Mar 2007 23:31:12 +0200 schrieb Norbert Hahn

Post by Norbert Hahn

Post by Hinnerk V
habe einen fileserver (windows2000) mit zwei FAT32-HDs. nach der
umstellung zur sommerzeit sind die Zeitstempel der Dateien jetzt eine
stunde hinter dem sicherungslaufwerk zurück.

Dann hat Dein Sicherungsprogramm ein Problem!
Ich kann z.B. bei TotalCommander beim Dateivergleich einstellen, dass
exakt eine Stunde Zeitdifferenz zu ignorieren ist. Das Problem kam
irgendwann mal mit NTFS oder Windows NT auf die Welt. Programme, die
jünger als 10 Jahre sind, sollten damit umgehen können.

suuupertipp!!
danke norbert!
genau mit dem total_commander synchronisiere ich auch.
is dann ja quasi die lösung. musste ein wenig suchen, bis ich die
einstellung fand, aber es funzt!
Hinnerk

Post by Norbert Hahn
Norbert