Dateidatum Erstellt/Geburt

[curt123]

Hallo,

wie komme ich an das Erstellungsdatum einer Datei? Mit stat bekomme ich ein leeres Feld angezeigt. Dabei hatte ich erwartet, dass das Datum ganz einfach in Thunar als Anzeigeoption verfügbar ist.

LG

[Meillo]

wie komme ich an das Erstellungsdatum einer Datei? Mit stat bekomme ich ein leeres Feld angezeigt.

`stat' zeigt an was im Dateisystem (in der Inode) gespeichert ist. Wenn es dort leer ist, ist es nicht gespeichert.

[willy4711]

Interessante Frage.
Relativ leicht nachprüfbar z.B. bei einer Log- Datei:
Erster Eintrag:

Code: Alles auswählen

Start-Date: 2020-08-01  10:46:45

Daten mit stat.

Code: Alles auswählen

stat /var/log/apt/history.log
  Datei: /var/log/apt/history.log
  Größe: 38932     	Blöcke: 88         EA Block: 4096   reguläre Datei
Gerät: 10301h/66305d	Inode: 1573096     Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Zugriff    : 2020-08-24 08:08:31.611591243 +0200
Modifiziert: 2020-08-23 11:30:57.687321598 +0200
Geändert   : 2020-08-23 11:30:57.687321598 +0200
 Geburt    : -

Wenn es dort leer ist, ist es nicht gespeichert.

Gibt es denn Überhaupt Einstellungen das Erstellungsdatum zu speichern ? Wäre manchmal schon interessant.
Schließlich gibt es ja das Feld "Geburt"

[willy4711]

Da scheint irgendetwas durcheinander zu gehen:
/var/log/apt/term.log
Erster Eintrag:

Code: Alles auswählen

Log started: 2020-08-01  10:46:45

Code: Alles auswählen

~$ stat /var/log/apt/term.log
  Datei: /var/log/apt/term.log
  Größe: 235478    	Blöcke: 472        EA Block: 4096   reguläre Datei
Gerät: 10301h/66305d	Inode: 1573079     Verknüpfungen: 1
Zugriff: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (    4/     adm)
Zugriff    : 2020-08-01 07:49:12.929822668 +0200
Modifiziert: 2020-08-23 11:30:57.687321598 +0200
Geändert   : 2020-08-23 11:30:57.687321598 +0200
 Geburt    : -

Die Diff wird wohl von logrotate kommen. Damit wäre Zugriff= Geburt

Nach dem "rein schauen" (musste ich ja) ist der "Zugriff" das aktuelle Datum/Uhrzeit

Code: Alles auswählen

Zugriff    : 2020-08-24 08:26:57.543937267 +0200

[MSfree]

`stat' zeigt an was im Dateisystem (in der Inode) gespeichert ist. Wenn es dort leer ist, ist es nicht gespeichert.

Wobei Linuxdateisysteme (ext*, xfs, btrfs) grundsätzlich ein Erstellungsdatum speichern.
Vermutlich hat curt123 ein "fremdes" Dateisystem gemountet, z.B. VFAT.

[willy4711]

Wobei Linuxdateisysteme (ext*, xfs, btrfs) grundsätzlich ein Erstellungsdatum speichern.

Scheint aber nicht so zu sein.

[MSfree]

Scheint aber nicht so zu sein.

Hmpf, ich hätte schwören können, daß das so ist
Aber scheinbar braucht man/ich das so selten, daß es mir bisher auch nicht aufgefallen ist.

[willy4711]

Ist mir ja auch noch nicht aufgefallen. Hab noch Schriftverkehr aus dem Jahr 1997.
Jetzt trau ich mich nicht, das zu öffnen

[MSfree]

Jetzt trau ich mich nicht, das zu öffnen

Das würde aber nur die Access-Time ändern. Die Modification-Time ändert sich erst, wenn man die geöffnete Datei auch speichert statt sie unverändert zu schließen.

[Meillo]

Es liegt wohl daran, dass es urspruenglich kein Geburtsdatum gab. Siehe z.B. https://pubs.opengroup.org/onlinepubs/9 ... tat.h.html und die Manpage stat(2). Es gibt atime, mtime und ctime. Die Geburtszeit ist eine Erweiterung.

Dazu auch:

Underlying kernel interface
Over time, increases in the size of the stat structure
have led to three successive versions of stat():
sys_stat() (slot __NR_oldstat), sys_newstat() (slot
__NR_stat), and sys_stat64() (new in kernel 2.4; slot
__NR_stat64). The glibc stat() wrapper function hides
these details from applications, invoking the most recent
version of the system call provided by the kernel, and
repacking the returned information if required for old
binaries. Similar remarks apply for fstat() and lstat().

Die Geburtszeit muss also vom Dateisystem gespeichert werden koennen und der Kernel muss beim Schreiben und Lesen einen der neueren Systemcalls mit dem erweiterten Stat-Struct verwenden. Stat(1) zu Anzeige scheint es ja schon zu koennen.


Ist das Verhalten mit einem aktuellen Kernel und neu angelegtem Dateisystem denn auch so, dass keine Geburtszeit abgelegt wird?

Weiss jemand welche Dateisysteme tatsaechlich die Geburtszeit in der Inode speichern koennen?

[willy4711]

Ist das Verhalten mit einem aktuellen Kernel und neu angelegtem Dateisystem denn auch so, dass keine Geburtszeit abgelegt wird?

Dieses Dateisystem (ext4) hab vor ca. 2 Monaten angelegt, Testing.
Also "ziemlich" aktuell

[MSfree]

Es gibt atime, mtime und ctime. Die Geburtszeit ist eine Erweiterung.

atime ist die Access-Time, also die Zeit des letzten Zugriffs.
mtime ist die Modification-Time, also die Zeit des letzten Schreibzugriffs.
ctime ist die Creation-Time, was ich mal als die Geburtszeit interprätieren würde.

[Meillo]

Es gibt atime, mtime und ctime. Die Geburtszeit ist eine Erweiterung.

atime ist die Access-Time, also die Zeit des letzten Zugriffs.
mtime ist die Modification-Time, also die Zeit des letzten Schreibzugriffs.
ctime ist die Creation-Time, was ich mal als die Geburtszeit interprätieren würde.

Nein.

Siehe:

time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */

[...]

The field st_atime is changed by file accesses, for example,
by execve(2), mknod(2), pipe(2), utime(2) and read(2) (of
more than zero bytes). Other routines, like mmap(2), may or
may not update st_atime.

The field st_mtime is changed by file modifications, for
example, by mknod(2), truncate(2), utime(2) and write(2) (of
more than zero bytes). Moreover, st_mtime of a directory is
changed by the creation or deletion of files in that direc-
tory. The st_mtime field is not changed for changes in own-
er, group, hard link count, or mode.

The field st_ctime is changed by writing or by setting inode
information (i.e., owner, group, link count, mode, etc.).

Ctime bedeutet ``change time'', d.h. die letzte Aenderung an der Inode, im Gegensatz zur mtime als letzte Aenderung am Inhalt der Datei.

[curt123]

Ich hab dazu noch etwas (unbestätigt?) gefunden, https://unix.stackexchange.com/question ... ion%204.11. :

Note that on Linux this requires coreutils 8.31, glibc 2.28 and kernel version 4.11 or newer.

The POSIX standard only defines three distinct timestamps to be stored for each file: the time of last data access, the time of last data modification, and the time the file status last changed.

Modern Linux filesystems, such as ext4, Btrfs and JFS, do store the file creation time (aka birth time), but use different names for the field in question (crtime in ext4, otime in Btrfs and JFS). Linux provides the statx(2) system call interface for retrieving the file birth time for filesystems that support it since kernel version 4.11.

Bei mir, debian 10.4, sind offenbar ("nur") coreutils 8.30-3 installiert. Kernelversion 4.19.0., glibc 2.28- , würde nach o.g. Quelle wohl passen.

Grundsätzlich finde ich die ganze Sache, wenn ich den derzeitigen Zustand richtig verstehe, katastrophal. Ich benötige die Erstellungszeit immer wieder mal, und zwar um sinnvoll arbeiten zu können auch im Dateimanager.

LG

[willy4711]

Note that on Linux this requires coreutils 8.31, glibc 2.28 and kernel version 4.11 or newer.

Na dann kann ich mir ja Hoffnungen machen

Code: Alles auswählen

 rmadison coreutils
coreutils  | 8.23-4        | oldoldstable   | source, amd64, armel, armhf, i386
coreutils  | 8.26-3        | oldstable      | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
coreutils  | 8.30-3        | stable         | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
coreutils  | 8.30-3        | testing        | source, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
coreutils  | 8.30-3        | unstable       | source, arm64
coreutils  | 8.30-3        | unstable-debug | source
coreutils  | 8.30-3+b1     | testing        | amd64
coreutils  | 8.32-3        | unstable       | source, amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
coreutils  | 8.32-3        | unstable-debug | source

Vielen Dank an alle für die Aufklärung

[Meillo]

@curt123: fuer die Recherche!

Grundsätzlich finde ich die ganze Sache, wenn ich den derzeitigen Zustand richtig verstehe, katastrophal.

Die ersten 50 Jahre ist Unix recht gut ohne Creation-Date ausgekommen, allzu katastrophal kann es kaum gewesen sein.

... aber ich verstehe schon, dass es manchmal nuetzlich ist. Ab und an habe ich es mir auch gewuenscht.

Ich benötige die Erstellungszeit immer wieder mal, und zwar um sinnvoll arbeiten zu können auch im Dateimanager.

Kannst du die Faelle genauer beschreiben? Vielleicht gibt es auch andere Moeglichkeiten.

[curt123]

Die ersten 50 Jahre ist Unix recht gut ohne Creation-Date ausgekommen, allzu katastrophal kann es kaum gewesen sein.

Offenbar, was mich auch etwas erstaunt hat. Bei MacOS, https://ger.applersg.com/how-sort-files-date-mac , schaut es wohl etwas anders aus:

Mithilfe der datumsbasierten Sortierung in Mac OS können Sie Dateien nach "Datum geändert", "Erstellungsdatum", "Zuletzt geöffnet" und "Datum hinzugefügt" sortieren / Diese Optionen sind in praktisch jeder Version von Mac OS und Mac OS X verfügbar, es sollte nicht wichtig sein, welche Version der Systemsoftware Sie verwenden.

Kannst du die Faelle genauer beschreiben? Vielleicht gibt es auch andere Moeglichkeiten.

Ich sortiere öfters beliebige Dateien nach Erstelldatum, um was zu finden. Das ist also im Normalfall an einen Dateimanager gebunden, und soll auch ohne Aufwand schnell klappen. Dafür sind vermutlich die aktuelleren coreutils, aber wohl auch einen Dateimanger, der sich entspr. anpassen lässt, nötig.

Der konkrete Anlass jetzt sieht etwas anders aus, ich hatte eine LP mit einem besonderen MC-Tonabnehmer digitalisiert, und dabei aber die Umstände nicht ausreichend dokumentiert. Die Digitaliserung weist etwas Brumm auf, weswegen ich sie erst nicht verwenden wollte. Nun nochmal angehört und bearbeitet, das Ergebnis ist doch unerwartet gut. Nun möchte ich anhand des Datums feststellen, ob ich schon ein bestimmtes Kabel (Vergleich mit Kaufdatum) benutzt haben könnte oder nicht, um die Situation (für andere LP-Überspielungen) reproduzieren zu können. Die jetzt angezeigten Datums-Werte -geändert usw.- passen nicht und sind vielleicht auch noch durchs Kopieren verändert (da kann ich nochmal grundsätzlich schauen was passiert, auch wenn ich Dateien von externen Windows-Medien kopiere).

Sonst geht es z.B. um sehr viele Fotos, bei denen ich nicht in irgendwelche Exif-Daten schauen möchte, oder Exif ergänzen, Kommentare, ohne das frühere Datei-Datum nicht mehr zu haben. Oder was ist mit flac oder wav-Dateien, die vermutlich ein anderes Datum erhalten, wenn man die tags ändert? Statt mir da Gedanken um eine datumsneutrale Taggersoftware zu machen, scheint mir das Erstelldatum eigentlich richtiger und einfacher, wenn es denn verfügbar ist.

LG