Ich habe MOV Dateien von einer SD Card auf die Festplatte kopiert (Win 11pro), dabei war dann auf der Festplatte die Erstellungszeit um 2 Std später, stattt 16:30 auf 18:30.
Vom Rechner wieder auf die SD zurückkopiert, Zeit war wieder wie original.
Anderer Rechner:
MOV Dateien von derselben SD Card auf die Festplatte kopiert (Win 10), dabei war
die Erstellungszeit wie auf der SD, also wie es sein sollte.
Versuch: die SD Card an notebook (Win 10) - über Netzwerk auf Rechner Win 11pro – Zeitangaben waren richtig.
am Notebook (Win 10) mp4 Dateien auf SD Card kopiert, die Datei zeigt auf SD um 5 min mehr; wieder zurückkopiert , Zeit war wieder richtig.
SD von USB getrennt, den gleichen Versuch nochmal, die Zeiten waren in beiden Richtungen beim Kopieren gleich, also richtig angezeigt.
Hab im Netz schon gesucht aber nichts brauchbares gefunden.
Weiß nicht, wie mittlerweile Windows Dateien speichert, alle Zeitstempel in UTC? Oder immer noch alles in lokaler Zeit wie zu MS-DOS-Zeiten?
Die nächste Frage ist dann halt, welche Annahme für einen Wechseldatenträger gemacht wird, der ja oft beispielsweise von einer Kamera kommt, die nur irgendeine Zeit ganz ohne Zeitzoneninformation für sich führt.
(Im Prinzip müssten sie einen beim Einlegen eines Wechseldatenträgers festlegen lassen, in welcher Zeitzone die dort befindlichen Daten angenommen werden sollten.)
Weiß nicht, wie mittlerweile Windows Dateien speichert, alle Zeitstempel
in UTC? Oder immer noch alles in lokaler Zeit wie zu MS-DOS-Zeiten?
Lokal wird immer noch alles in lokaler Zeit gespeichert. Bei Netzlaufwerken: depends...
(Im Prinzip müssten sie einen beim Einlegen eines Wechseldatenträgers
festlegen lassen, in welcher Zeitzone die dort befindlichen Daten
angenommen werden sollten.)
Genau das dürfte der Knackpunkt sein. Default ist: treat as local time.
Das ist eine genauso beschissene Lösung wie jede andere denkbare auch. Jedenfalls so lange nicht sichergestellt ist, dass sämtliche "Spender" der Dateien immer und überall eine valide Eigenzeit hatten und ein Konsens darüber bestehen würde, in welcher Zeitzone diese Eigenzeit zu liegen hat.
Schon mal mit der rechten Maustaste in der Kopfzeile nachgesehen, was genau aktiviert war? Datum, Erstellungsdatum, Änderungsdatum, Aufnahmedatum, unter weitere sind noch mehr Varianten.
Mal 2 Stunden, mal 5 min, hmmm, könnte es sein, daß der Zeitpunkt der Einbindung (mounten) ins Dateisystem eine Rolle spielt ?
2 Stunden würde ja die Herkunft des Medium aus einem anderen Land (Zeitzone) bedeuten. ???
es müßte doch egal sein ob von wo die Kamera die Zeitinfos hernimmt,
entscheidend müßte doch sein dass die Daten beim kopieren nicht
verändert werden
Nur gehören manche Zeitstempel nicht zu den Daten, sondern zu den Metadaten von Dateien. Einige Metadaten werden nur beibehalten beim verschieben, nicht jedoch beim kopieren von Dateien.
Trifft hier nicht zu da es nur um die Zeitzone geht. Sollte man aber beachten wenn man USB-MTP benutzt um Daten von SD Karte zu kopieren.
Ich finde es muß egal sein in welcher Kamera die SD Karte verwendet wurde und welche Zeit eingestellt war, es befinden sich darauf Videodaten, diese Daten beinhalten Datum und Zeit;
der Kopiervorgang sollte alle Daten kopieren und nicht verändern;
Fehler im Win ??
Ich habe nun die,von der SD Card kopierten Daten in mein Videoschnittprogramm importiert und siehe da, ein weitere Spuk.
Siehe Anhang.
Links im Bild SD Card - Festplatte
rechts, zwei verschiedene Fenster, im Programm, in denen die Eigenschaften angezeigt werden; wieder verschiedene Zeiten.
Du hast bei Festplatte und SD-Karte im Explorer verschiedene Datumsspalten.
Das Schnittprogramm zeigt rechts zumindest Metadaten an, die in der Kamera falsch gespeichert werden, weil du die Uhr nicht auf Sommerzeit stehen hast.
Ich kopiere meine Files mit teracopy, der Bequemlichkeit wegen, und diese Probleme sind mir und Millionen anderer User völlig unbekannt.
Heißt: du hast entweder ein Problem mit der Bedienung deiner Geräte, oder eine falsche Einstellung.
Der Spuk unterschiedlicher Dateisysteme und Zeitzonen.
Kopiere ich Dateien von FAT32 auf ein NTFS-Laufwerk, haben sie die selbe Zeit. Dann kommt Sommerzeit, und auf einmal besteht zwischen FAT und NTFS eine Stunde Differenz, obwohl nichts verändert wurde.
Schaue mal auf dem PC den Zeitstempel einer Datei an, schalte Sommerzeit aus oder eine andere Zeitzone ein und wundere Dich: Unter NTFS verändert der sich, bei FAT bleibt er gleich.
Schaue mal auf dem PC den Zeitstempel einer Datei an, schalte Sommerzeit
aus oder eine andere Zeitzone ein und wundere Dich: Unter NTFS verändert
der sich, bei FAT bleibt er gleich.
Wenn man nicht versteht, was man macht, dann kann man auf derartige Rückschlüsse kommen. NTFS speichert UTC-Zeitstempel. Die sind eindeutig und verändern sich nicht.
Was Du als Veränderung warhnimmst, ist die /Umrechnung/ dieser Zeitstempel in irgendeine lokale Zeitzone, die das von Dir ungenannte Programm vornimmt, bevor es Dir diese Zeitstempel anzeigt.
FAT übrigens kann Zeitstempel nur auf ganze zwei Sekunden genau auflösen, das bedeutet, daß beim Kopieren von einem NTFS-Dateisystem auf ein FAT-Dateisystem der Zeitstempel irreversibel verändert wird.
Ach so, ja, wenn man Programme schreibt, kann das etwas interessant sein.
Das ist doch Datenbank-Dateimanagement-Zeugs, dafür interessiert man sich wenn man dauernd Konto-buchungen, Messwerte, Wikipedia-änderungen, usw abspeichert. Man kann für sich das Datum im Dateinamen verzeichnen, macht man manchmal.
Aber das Betriebssystem sollte doch mit Erstellung der Datei diesen Zeitpunkt bei der Datei vermerkt haben, tuts wahrscheinlich auch. Als normaler Win-user sieht man meist nur das Änderungsdatum. Wo sollte sich das Betriebssystem die Zeitangaben merken ? im Master Boot Record (oder im file allocation table) würde ich sagen oder in dem ntfs-Journal.
Was hat FAT damit zu tun, eigentlich nix, denke ich mir. in Wiki FAT sehe ich bei den Erweiterungen VFAT und LFN, daß jetzt der Dateinamensraum mit Erweiterung von 8+3 auf viel mehr Zeichen(255), dort auch Zeitangaben untergebracht werden können. Die Verlängerung des Dateinamens wird auf zusätzliche Extra-Dateien-Erzeugung verteilt. (Man hätte ja auch einen zusätzlichen Header in der Datei anlegen können.)
Es müssen die Dateizeitmarken zwar irgendwo gesetzt und abgespeichert sein, aber das ist nicht die Aufgabe des Dateisystems sondern doch eher des Betriebssystems, nur wo passiert das, bzw wo kann man da was ändern.
Soll das nun bedeuten, auf der wahrscheinlichen FAT-SD-Karte sind zusätzlichen Zeitmarken-dateien drauf (mit warum auch immer anderen Erstelldatum), die das ntfs-Betriebssystem fälschlicherweise für die eigentliche Hauptdatei-(das Bild)-Zeitmarke hält ?
Es müssen die Dateizeitmarken zwar irgendwo gesetzt und abgespeichert
sein, aber das ist nicht die Aufgabe des Dateisystems
Das Dateisystem definiert, wo/wie die Dateiattribute gespeichert werden.
Das Betriebsystem (bzw. dessen Dateisystem-Treiber) sollte sich möglichst an diese Definition halten.
Hat bei Dos (MS-Dos, DR-Dos, Novel-Dos, Open-Dos, Free-Dos, Win95ff, usw) mehr oder weniger geklappt...
FAT reserviert zwei Bytes für das Erstellungs-Datum (5 Bit für den Tag, 4 für den Monat, 7 für das Jahr ab 1980) ab Offset 0x0E in jedem Directory Entry
und zwei Bytes für die Uhrzeit (5 Bit für die "Doppelsekunde", 6 Bit für die Minute, 5 Bit für die Stunde) direkt dahinter.
Modification Datum/Uhrzeit im selben Format ab Offset 0x16
Wo sollte sich das Betriebssystem die Zeitangaben merken ?
Da, wo derartige Daten hingehören: In den zugehörigen Verzeichniseinträgen. Dort, wo auch steht, wie die Datei heißt, wie groß sie ist und welche Attribute sie hat.
im Master Boot Record (oder im file allocation table) würde
ich sagen oder in dem ntfs-Journal.
Nein, nun wirklich überhaupt gar nicht. Der erste hat mit dem Dateisystem überhaupt nichts am Hut, sondern enthält lediglich eine betriebs- und dateisystemagnostische Partitionstabelle, sowie eine Handvoll Bytes, die beim Booten fossiler PCs als Bootcode ausgeführt werden.
Die beiden anderen dienen mehr oder weniger nur der Information, wo denn die zu einer Datei gehörenden Daten zu finden sind.
Es müssen die Dateizeitmarken zwar irgendwo gesetzt und abgespeichert
sein, aber das ist nicht die Aufgabe des Dateisystems sondern doch eher
des Betriebssystems, nur wo passiert das, bzw wo kann man da was ändern.
Soll das nun bedeuten, auf der wahrscheinlichen FAT-SD-Karte sind
zusätzlichen Zeitmarken-dateien drauf (mit warum auch immer anderen
Erstelldatum), die das ntfs-Betriebssystem fälschlicherweise für die
eigentliche Hauptdatei-(das Bild)-Zeitmarke hält ?
Nein. Da sind keine "Zeitmarken-Dateien" drauf und das NTFS-Dateisystem speichert die korrekten Zeitstempel.
Es gibt aber Dateien, die wiederum Metadaten enthalten - bei Bildern, die mit einer Digitalkamera angefertigt werden, sind das die sog. "EXIF"-Daten. Die können von manchen Betriebssystemen (wie z.B. Windows) angezeigt werden, die sind aber kein Bestandteil der Verwaltung durch ein Dateisystem und werden vom Betriebssystem auch nicht geändert.
Der Screenshot weiter oben von "pawl" zeigt, wie man das alles sehr schön durcheinanderwerfen kann.
Wo sollte sich das Betriebssystem die Zeitangaben merken ?
Da, wo derartige Daten hingehören: In den zugehörigen
Verzeichniseinträgen.
Allgemeiner gesagt: da, wo alle Metadaten für die Datei stehen.
Bei FAT und NTFS ist das der Verzeichniseintrag. Bei allen unixoiden Dateisystemen ist das der i-Node, und die Verzeichniseinträge zeigen auf diesen.
Das Problem bei FAT ist nur, dass sie zwar (wie viele andere aus dieser Zeit) das Dateidatum letztendlich auch in 32 Bit speichern, aber sie speichern es nicht einfach als Sekunden gegenüber irgendeinem Startzeitpunkt, sondern sie speichern es decodiert, auf einzelne Bitfelder aufgeteilt nach Jahr, Monat, Tag, Stunden, Minuten und Sekunden. Nicht nur, dass da schlicht gar kein Platz mehr für eine Zeitzonen-Information ist (eine elektronisch auf die andere Seite der Erde damit übertragene Datei könnte also aus der Zukunft stammen), sondern es verschwendet gegenüber einer einfachen 32-Bit-Zahl auch einiges an Platz. Daher war der Bereich für die Sekunden so klein, dass man die Sekundenzahl nur noch halbiert unterbringen kann, es gibt also nur geradzahlige Sekunden.
Die Idee mit den "Zeitmarken-Dateien" gab's übrigens tatsächlich mal, vor DOS, bei CP/M, als das möglichst backward-compatible dazugefrickelt worden ist.
Waren dann Files mit Namen "!!!TIME&.DAT".
Alternativ gab's bei "CP/M Plus" native Timestamps pro Extend (nicht pro Datei). Lustigerweise Kodiert als zwei Bytes "Tage ab 1978", 1 Byte Stunde, 1 Byte Minute.
Die Minuten&Stunden jeweils BCD-Kodiert...
wenn möglich, sollte ein Prog das Datum IMMER auch
direkt im Dateinamen ablegen.
Nun geht's hier um die Uhrzeit. Tatsächlich dürfte die Uhrzeit selten relevant sein. Bei den Hochzeitsfotos von Onkel Heiner und Tante Berta dürfte der Tag wesentlich sein, aber wen interessiert, wann genau die Hochzeitstorte angeschnitten wurde oder wann Schwiegervater die braune Soße auf das weiße Hochzeitskleid geschüttet hat?
Also, danke für die Erklärungen zum Dateisystem "Offset 0x0E ...". allerdings ist mir immer noch nicht klar was da passiert ist.
ich gehe mal davon aus, daß Ntfs die Utc als Standardzähler führt und also die Sommerzeit erstmal nicht mitmachen muß, sondern dies nur als zusätzliches +?h anfügt, es aber so keine doppelten Zeiteinträge bei der Winterzeitumstellung gibt.
Von Fat-sdcard (und dessen möglicherweise falsch eingestellter Zeit) wird also deren anderes Zeitformat übernommen (als Utc) und mit dem Pc-gültigen Utc +1h Zeitzonenbetrag addiert und zusätzlich mit dem gerade gültigen Sommerzeit +1h Stundenzähler addiert. Und dies also kalenderentsprechend ?
Das Problem bei FAT ist nur, dass sie zwar (wie viele andere aus dieser
Zeit) das Dateidatum letztendlich auch in 32 Bit speichern, aber sie
speichern es nicht einfach als Sekunden gegenüber irgendeinem
Startzeitpunkt, sondern sie speichern es decodiert, auf einzelne
Bitfelder aufgeteilt nach Jahr, Monat, Tag, Stunden, Minuten und
Sekunden. Nicht nur, dass da schlicht gar kein Platz mehr für eine
Zeitzonen-Information ist
Meine beiden Canon-Kompaktkameras zeigen im Einstellmenue eine Weltkarte mit Zeitzonen und einen Schalter für Sommerzeit. Die zugehörige SD-Karte ist FAT32, die das garnicht speichern kann - da hat ein Softwerker nicht mitgedacht.
(eine elektronisch auf die andere Seite der
Erde damit übertragene Datei könnte also aus der Zukunft stammen),
Das sollte bei NTFS nicht passieren, eine jetzt um 23:30 gespeicherte Datei sollte dann in den USA 17:30 zeigen.
Die zugehörige SD-Karte ist FAT32, die das garnicht speichern kann - da
hat ein Softwerker nicht mitgedacht.
Die braucht aber halt die korrekte lokale Zeit, denn die wird gespeichert. Wenn du jetzt fotografierst, soll da also auch 06:32 stehen und nicht 04:32 (UTC) oder 05:32 (MEZ).
Die zugehörige SD-Karte ist FAT32, die das garnicht speichern kann - da
hat ein Softwerker nicht mitgedacht.
Die braucht aber halt die korrekte lokale Zeit, denn die wird
gespeichert. Wenn du jetzt fotografierst, soll da also auch 06:32 stehen
und nicht 04:32 (UTC) oder 05:32 (MEZ).
Windows macht dann genau das, was Paul irritiert: Auf FAT kopiert, bleibt die angezeigte Änderungszeit gleich, unter NTFS verändert sie sich abhängig von der Zeiteinstellung des PCs.
Das Erstelldatum hat keinen Bezug zur Aufnahmezeit, das ist die PC-Zeit, wo die Datei von der SD auf die Platte kopiert wurde. Das könnte seine Versätze von wenigen Minuten erklären.
Deswegen habe ich Teracopy standardmäßig aktiv.
Nicht das ich irgendwas auf die Dateidaten gäbe, aber Teracopy macht das automatisch so, und bislang hat es mich nicht gestört.
Ich hab das jetzt extra getestet, und bei meiner Canon Ixus die Zeit 10 Minuten vorgestellt.
Dann die Karte in den PC gesteckt: 16GB SD mit FAT32
Erstellt Freitag 3. Mai 19:40:23
Geändert Freitag 3. Mai 19:40:22
Letzter Zugriff Heute, 3. Mai (ohne Zeit)
Da dürfte die eine Sekunde differenz wohl an der FAT32-Doppelsekunde liegen.
Dann kopiere ich das File auf meine lokale Festplatte, 1TB NTFS
Erstellt Freitag 3. Mai 19:40:23
Geändert Freitag 3. Mai 19:40:22
Letzter Zugriff Heute, 3. Mai, vor 1 Minute
Das Bild wurde für die Kamera um 19:40 aufgenommen, und genau das wird auch kopiert, obwohl es jetzt erst 19:32 ist.
Allerdings, ja, stelle ich die Zeitzone um, ändert sich die Anzeige der Zeit auf dem NTFS-Datenträger, was ich unlogisch finde, auch wenn ich die Herkunft der Verschiebung logisch verstehe.
Allerdings: kopiere ich die Datei erneut, mit verschobener Zeitzone oder falschem Sommerzeithaken, so bekommt sie wieder die "korrekte Zeit" 19:40 in die Eigenschaften kopiert.
Stelle ich die Uhr dann wieder korrekt, wandern die Zeiten lustig umher, auch in die Zukunft.
Kopiere ich mit dem Explorer, so ist die "Erstellt:"-Zeit immer die aktuelle Zeit.
In den Metadaten, die z.B. die Windows-10-Fotoanzeige unter dem "i im Kreis" oder der Windows-Explorer unter Details/Aufnahmedatum anzeigt, bleibt aber die 19:40 stehen, egal wie die Zone ist, denn das ist das korrekte Datum der Erstellung.
Das Erstelldatum hat keinen Bezug zur Aufnahmezeit, das ist die PC-Zeit,
wo die Datei von der SD auf die Platte kopiert wurde.
Das ist korrekt, wenn man im Explorer kopiert.
Wenn man das einheitlich haben will, muss man z.B. mit teracopy kopieren, dann ist das Datum beider Files identisch. Ich denke das andere Kopiertools das ebenso handhaben.
Und bei Zeitzonenänderung (und Sommerzeit) ändern sich sowohl "Erstellt:" als auch "Geändert:" synchron um eben die Stunde(n).
Für die die Teracopy nicht kennen:
Es handelt sich um eine Erweiterung des Explorer-Kopierdialogs, der z.B. CRC-Überprüfung, eine bessere Fortschrittsanzeige und Pause/Fortsetzen ermöglicht.
Ich nutze die alte Version 2.3, die mir besser gefällt als die aktuelle, aber leider nicht mehr vom Hersteller ausgeliefert wird. Aktuelle Version bei https://www.codesector.com/downloads, die 2.3 gibt's noch z.B. bei Chip.
Und ja, läuft auch unter W10 und W11 x64 noch einwandfrei.
"Erstellt" ist normalerweise der Zeitpunkt, an dem die Datei im Dateisystem angelegt wurde.
Daher ändert sich diese Angabe auch, wenn der Explorer das File neu auf einem anderen Datenträger erzeugt: "hier" ist die neu.
Teracopy nimmt das aber mit, weil die Datei ja reell auf dem Quelldatenträger erstellt wurde.
Robocopy und andere Tools handhaben das auch so.
"Geändert am" ist das Datum, an dem zuletzt in die Datei geschrieben wurde. Das ist ja unverändert und meist das eigentliche Erstelldatum.
Danke, daß ihr das so deutlich herausgearbeitet habt, langsam verstehe ich es.
in Win7 gibt es unter Dienste einen Windows-Zeitgeber "W32Time" programm: "svchost.exe -k Local Service" , da werde ich aber nicht dran drehen.
Wozu auch, das ist die normale Windows-Uhr.
Wenn der dienst nicht läuft, geht die Uhr nicht weiter, das macht nur noch mehr Ärger als eine falsche Uhr.
Lass deine Computer die Zeit vom Router holen (und stell die Zone richtig ein), dann haben die automatisch alle Atomzeit.
Bei der Kamera kannst du nur dein bestes geben, also Lokalzeit korrekt einstellen, Zone und Sommerzeit wenn du kannst auch, wenn nicht dann eben nicht.
Den Rest müssen die Metadaten erledigen, da hilft es dann wenn du im Explorer die Spalten korrekt nutzt, aber nicht jede Datei hat ein Datum in den Metadaten, dann bekommst du halt auch viele Files in denen die Spalte leer bleibt.
Ob es sinnvoll ist, die Fotos zusammen komprimiert zu transportieren. Dann ändert sich nur das Datum des zip oder rar bis sie wieder ausgepackt werden?
Unzip oder Unrar macht auch nichts anderes als Teracopy: nach dem Erstellen der Datei wird das vom OS vergebene Erstellungsdatum "jetzt" auf das in dem Archiv bzw. bei der Quelle hinterlegte geändert.
Zippen macht nur Sinn wenn man z.B. via Mail transportieren muss, weil eine Datei einfacher zu benutzen ist. Und evtl. Fehlererkennungsdaten beinhaltet.
Svchost ist bei meinem Windows7 in 17 Versionen gestartet und wird wohl die Stechuhr machen.
insgesamt ist es wohl blöd, daß Windows das Orginaldatum zu behalten nicht anbietet.
Wozu auch, das ist die normale Windows-Uhr.
Wenn der dienst nicht läuft, geht die Uhr nicht weiter, das macht nur
noch mehr Ärger als eine falsche Uhr.
Du schreibst genauso viel Mist wie dieser carypt!
Wenn der Dienst "w32time" beendet oder garnicht erst gestartet wird, passiert lokal genau garnichts. Natürlich läuft die Uhrzeit weiter. W32time ist (nur) für die Zeitsynchronisation im Netzwerk zuständig.
Ob es sinnvoll ist, die Fotos zusammen komprimiert zu transportieren.
Dann ändert sich nur das Datum des zip oder rar bis sie wieder
ausgepackt werden?
Wenn man lokal kopiert, bringt das keinen Vorteil. Beim Versand per email oder http-download sieht das anders aus, da geht das Datum verloren und kann erhalten werden, wenn man gepackt überträgt. Deine Idee kann Sinn machen, abhängig vom Szenario.
Unzip oder Unrar macht auch nichts anderes als Teracopy: nach dem
Erstellen der Datei wird das vom OS vergebene Erstellungsdatum "jetzt"
auf das in dem Archiv bzw. bei der Quelle hinterlegte geändert.
Kannst Du noch etwas anderes als hier ständig mit Deinem Unwissen zu prahlen?
Das Entpacken einer ZIP rettet das Änderungsdatum, das Erstelldatum entspricht dem Datum des Entpackens. Synchronisieren aller Metadaten, Zeit und Berechtigungen, ist speziellen Tools vorbehalten, keinesfalls den üblichen Packern.
Svchost bedeutet ungefähr so viel wie "dingsbums".-)
Sysinternals Process Explorer (2006 aufgekauft von Microsoft) ist nach
wie vor kostenlos erhältlich.
Im Gegensatz zu Dir traue ich Stefan zu, den Process Explorer benutzen zu können. Wird er aber in diesem Fall nicht tun, der Unfug ist auch so offensichtlich.
