Hallo 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. Hat da jemand eine Erklärung dafür? Für einen Tipp wäre ich dankbar Freundliche Grüße Paul
Paul W. schrieb: > Hat da jemand eine Erklärung dafür? Zeitzonen-Offset 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.)
:
Bearbeitet durch Moderator
Win 7 musste man explizit sagen, dass man UTC Zeit haben möchte und die lokale angezeigt. Weiß nicht, wie das bei 8..11 ist.
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 lg Paul
Jörg W. schrieb: > 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.
:
Bearbeitet durch User
Jörg W. schrieb: > Weiß nicht, wie mittlerweile Windows Dateien speichert, alle Zeitstempel > in UTC? Oder immer noch alles in lokaler Zeit wie zu MS-DOS-Zeiten? Kommt aufs Dateisystem an. NTFS verwendet schon seit 1993 UTC. FAT hingegen verwendet die lokale Zeitzone.
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. ???
Carypt C. schrieb: > 2 Stunden würde ja die Herkunft des Medium aus einem anderen Land > (Zeitzone) bedeuten. ??? 2 Stunden sind der Unterschied zwischen UTC und CEST ("MESZ"). Benutzt Du möglicherweise irgendein "Schlaumi"-Programm, mit dem Du Dir auf Deinem PC die Dateizeiten anzeigen lässt?
Harald K. schrieb: > 2 Stunden sind der Unterschied zwischen UTC und CEST ("MESZ"). Und 5 Minuten vielleicht eine nicht korrekte Uhr in der Kamera?
Paul W. schrieb: > 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
SD_Card_.jpg
390 KB
Danke für die vielen Meinungen. 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. man muß wohl damit leben..... Danke und liebe Grüße Paul
oder man nutzt Exif Daten oder richtige Zeitstempel im Bild
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.
:
Bearbeitet durch User
Paul W. schrieb: > ein weitere Spuk 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.
Es kommt auch darauf an, womit man kopiert. robocopy /? zeigt einige Optionen.
Manfred P. schrieb: > 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. (NTFS verwendet eine Auflösung von 100 nsec)
Woher weiß man denn sowas ? in welchem Zusammenhang / Betätigungsfeld stolpert man über diese information ? Nur so aus interesse.
:
Bearbeitet durch User
Carypt C. schrieb: > in welchem Zusammenhang / Betätigungsfeld stolpert man über diese > information ? Immer dann, wenn man sich jemals mit FAT befasst hat.
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 ?
:
Bearbeitet durch User
Carypt C. schrieb: > 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
Carypt C. schrieb: > 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. Carypt C. schrieb: > 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. Natürlich ist das eine Aufgabe des Dateisystems. Carypt C. schrieb: > 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. Übrigens: Du plenkst. Lass das.
Harald K. schrieb: >> 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...
Paul W. schrieb: > Für einen Tipp wäre ich dankbar wenn möglich, sollte ein Prog das Datum IMMER auch direkt im Dateinamen ablegen.
●DesIntegrator ●. schrieb: > wenn möglich, sollte ein Prog das Datum IMMER auch > direkt im Dateinamen ablegen. Und welches Problem soll das lösen?
●DesIntegrator ●. schrieb: > wenn möglich, sollte ein Prog das Datum IMMER auch > direkt im Dateinamen ablegen. Warum sollte es?
So kann man jederzeit mit einem Skript über die Dateinamen laufen und die mtime wiederherstellen. Besser ist natürlich exif wenn vorhanden.
●DesIntegrator ●. schrieb: > Paul W. schrieb: >> Für einen Tipp wäre ich dankbar > > 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?
Rainer Z. schrieb: > Nun geht's hier um die Uhrzeit Hatte ich als gegeben angesehen. so wie das Handies halt auch machen.
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 ?
Jörg W. schrieb: > 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. Rainer Z. schrieb: > Nun geht's hier um die Uhrzeit. Tatsächlich dürfte die Uhrzeit selten > relevant sein. Für Dich vielleicht nicht. Wenn man Datensicherung betreibt, im simpelsten Fall mit "xcopy /d", muß eindeutig sein, was neuer ist.
Manfred P. schrieb: > 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).
Angehängte Dateien:
-
MESZ.png
19 KB -
MEZ.png
18 KB -
NewYork.png
18 KB -
Erstellt.png
5 KB
Jörg W. schrieb: >> 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.
Und "geändert am" bleibt gleich.
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. Manfred P. schrieb: > 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.
Jörg W. schrieb: > Und "geändert am" bleibt gleich. "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.
Jörg W. schrieb: > Und "geändert am" bleibt gleich. Das bleibt es eben nicht, vergleiche MEZ - MESZ - NY unter dem violetten NTFS.
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.
Manfred P. schrieb: > Das bleibt es eben nicht, vergleiche MEZ - MESZ - NY unter dem violetten > NTFS. Und? GMT ist immer gleich.
Carypt C. schrieb: > 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.
Paul W. schrieb: > Erstellungszeit um 2 Std > später, stattt 16:30 auf 18:30. Die geistige Unterbelichtung kann man mit der Sommerzeit abschaffen.
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.
Carypt C. schrieb: > Svchost ist bei meinem Windows7 in 17 Versionen gestartet Svchost bedeutet ungefähr so viel wie "dingsbums".-) Das ist eine exe Datei, die der Ausführung weiterer Programme im DLL Format dient. Wird auch neben guten Dingen auch gerne zum Verbergen von bösartigen Programmen verwendet.
:
Bearbeitet durch User
Carypt C. schrieb: > Svchost ist bei meinem Windows7 in 17 Versionen gestartet Steve van de Grens schrieb: > Svchost bedeutet ungefähr so viel wie "dingsbums".-) Sysinternals Process Explorer (2006 aufgekauft von Microsoft) ist nach wie vor kostenlos erhältlich.
:
Bearbeitet durch User
Alexander schrieb: > Sysinternals Process Explorer ... und für Leute, die verstehen, was das Ding anzeigt, die deutlich bessere Alternative zum Taskmanager. https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer
Mo schrieb: > Jörg W. schrieb: >> nur geradzahlige Sekunden > > https://de.wikipedia.org/wiki/Sekundant die Satisfaktion ist bei FAT aber eher sekundär
Alexander schrieb: > die Satisfaktion ist bei FAT aber eher sekundär Zweiter Platz im Duell ... klingt doch nicht schlecht, oder?
Der andere wurde leider nur Vorletzter.
Jörg W. schrieb: > Der andere wurde leider nur Vorletzter. Sehr schön. Fast vorbei ist auch daneben.
Jens M. schrieb: > Carypt C. schrieb: >> 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. 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. Lu schrieb: > 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. Jens M. schrieb: > 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. Mo schrieb: > Die geistige Unterbelichtung stellst Du hier zur Schau, hast Dich offenbar neu an- bzw. umgemeldet, um Mist zu schreiben. Alexander schrieb: > Steve van de Grens schrieb: >> 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.
Jörg W. schrieb: > Der andere wurde leider nur Vorletzter. -1 Als Moderator solltest Du diesen Dummlall nicht füttern, wo die bekannten Schwachmaten wetteifern, wer den größten Unfug abgesondert bekommt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.