Holen Sie sich die Dateierstellungszeit mit Python auf Linux

Question

Os.stat gibt die Attribute st_mtime und st_ctime zurück, die Änderungszeit ist st_mtime und st_ctime "Änderungszeit" auf POSIX. Gibt es eine Funktion, die die Erstellungszeit einer Datei unter Verwendung von Python und unter Linux zurückgibt?

Answer 1

Du kannst wahrscheinlich es nicht.:

3.1)  Wie finde ich die Erstellungszeit einer Datei?

      Das kannst du nicht - sie wird nirgendwo gespeichert. Dateien haben eine letzte Änderungszeit
      (angezeigt durch "ls -l"), eine letzte Zugriffszeit (angezeigt durch "ls -lu")
      und eine Inode-Änderungszeit (angezeigt durch "ls -lc"). Letzteres wird oft
      als "Erstellungszeit" bezeichnet - sogar in einigen Man-Pages -
      aber das ist falsch; es wird auch durch Operationen wie mv, ln,
      chmod, chown und chgrp gesetzt.

      Die Man-Page für "stat(2)" erläutert dies.

Answer 2

Versuch es:

st_birthtime

Auf allen Systemen ist es jedoch nicht garantiert verfügbar. Aus der Dokumentation:

Auf einigen Unix-Systemen (wie Linux) können auch die folgenden Attribute verfügbar sein: st_blocks (Anzahl der für die Datei allokierten Blöcke), st_blksize (Dateisystem-Blockgröße), st_rdev (Gerätetyp, falls es sich um ein Inode-Gerät handelt), st_flags (benutzerdefinierte Flags für die Datei).

Auf anderen Unix-Systemen (wie FreeBSD) könnten die folgenden Attribute verfügbar sein (werden jedoch möglicherweise nur ausgefüllt, wenn der Root-Benutzer versucht, sie zu verwenden): st_gen (Dateierzeugungsnummer), st_birthtime (Erstellungszeit der Datei).

http://docs.python.org/2/library/os.html#os.stat

Answer 3

Aufgrund des Mangels an einem guten Dienstprogramm habe ich crtime erstellt.

pip install crtime

Dann kannst du es so verwenden:

sudo crtime ./

Würde Folgendes ausgeben:

1552938281  /home/pascal/crtime/.gitignore
1552938281  /home/pascal/crtime/README.md
1552938281  /home/pascal/crtime/crtime
1552938281  /home/pascal/crtime/deploy.py
1552938281  /home/pascal/crtime/setup.cfg
1552938281  /home/pascal/crtime/setup.py
1552938961  /home/pascal/crtime/crtime.egg-info
1552939447  /home/pascal/crtime/.git
1552939540  /home/pascal/crtime/build
1552939540  /home/pascal/crtime/dist

Beachten Sie, dass es für große Verzeichnisse um ein Vielfaches schneller als xstat oben ist, da dies eine temporäre Datei erstellt und dann stat-Aufrufe für alle Dateien gleichzeitig ausführt.

In Python (vergesst nicht, dass ihr es auf Linux immer noch mit sudo aufrufen müsst):

from crtime import get_crtimes, get_crtimes_in_dir
get_crtimes_in_dir("./")

Answer 4

Laut einem Thread hier verfolgen auch OS X's HFS und Microsoft's NTFS beide die Erstellungszeit, und mir wurde gesagt, dass die OS X- und Cygwin-Versionen von stat() diese Informationen zurückgeben. was laut der OSX stat Manpage zumindest für Mac richtig zu sein scheint:

a, m, c, B

Die Zeit, zu der die Datei zuletzt zugegriffen oder geändert wurde, oder wann der Inode zuletzt geändert wurde, oder die Geburtszeit des Inodes.

Für neuere Linux-Dateisysteme wie ext4, Btrfs und JFS unterstützen dies mit debugfs, es gibt eine Bash-Funktion, die von hier übernommen wurde, die den Datum-erstellt-Zeitstempel extrahiert:

Sie können das Datei-Erstellungsdatum wiederherstellen, wenn Sie mit einem geeigneten Dateisystem wie EXT4 arbeiten - journaling Dateisystem für Linux:

Verbesserte Zeitstempel

... Ext4 bietet Zeitstempel in Nanosekunden an. Zusätzlich bietet ext4 auch Unterstützung für Datum-erstellt-Zeitstempel. Aber in der Community gibt es keine Einigkeit darüber, so

... wie Theodore Ts'o anmerkt, es ist zwar einfach, ein zusätzliches Erstellungsdatum-Feld im Inode hinzuzufügen (und damit technisch die Unterstützung für Datum-erstellten-Zeitstempel in ext4 zu aktivieren), es ist jedoch schwieriger, die erforderlichen Systemaufrufe wie stat() zu ändern oder hinzuzufügen (was wahrscheinlich eine neue Version erfordern würde) und die verschiedenen Bibliotheken, die von ihnen abhängen (wie glibc). Diese Änderungen erfordern die Koordination vieler Projekte. Also, selbst wenn die ext4-Entwickler eine anfängliche Unterstützung für Erstellungsdatum-Zeitstempel implementieren, wird dieses Feature vorerst nicht für Benutzerprogramme verfügbar sein. Was zu Linus' abschließendem Zitat führt

Warten wir fünf Jahre und sehen, ob tatsächlich Konsens darüber besteht, ob es überhaupt benötigt und genutzt wird, anstatt sich in etwas zu stürzen, nur weil "wir können".

xstat() {
  for target in "${@}"; do
    inode=$(ls -di "${target}" | cut -d ' ' -f 1)
    fs=$(df "${target}"  | tail -1 | awk '{print $1}')
    crtime=$(sudo debugfs -R 'stat <'"${inode}"'>' "${fs}" 2>/dev/null | 
    grep -oP 'crtime.*--\s*\K.*')
    printf "%s\t%s\n" "${crtime}" "${target}"
  done
}

Wenn es ausgeführt wird, gibt es das Erstellungsdatum zurück:

:~$ echo 'print("hello world")' > blah.py
:~$ xstat "blah.py"
Mon Jul  6 13:43:39 2015    blah.py
:~$ echo 'print("goodbye world")' > blah.py
:~$ xstat "blah.py"
Mon Jul  6 13:43:39 2015    blah.py

Also, wenn das Dateisystem es unterstützt, ist es möglich, andernfalls könnten Sie debugfs mit Unterprozessen ausführen und die Ausgabe analysieren.

Answer 5

Du könntest erklären, warum du das tun möchtest.

Ein indirekte Lösung könnte sein, ein Versionsverwaltungssystem (auch Versionskontrollsystem = VCS) zu verwenden, um die Dateien zu verwalten, deren Erstellungszeit benötigt wird.

Also könntest du git für solche Dateien verwenden (d.h. sie als "Quellcode" behandeln). Dann weißt du nicht nur, wann sie erstellt wurden (tatsächlich im VCS registriert mit git add), sondern auch warum, von wem, wofür usw... Verwende git log, um all diese Informationen zu bekommen...

Natürlich musst du deine Benutzer irgendwie dazu erziehen, ein VCS wie git zu verwenden.