Speichert BTRFS eigentlich das Erstellungsdatum einer Datei? Alle aktuellen Linux-FS' speichern lediglich das Datum der letzten Modifikation. Meiner Meinung nach eine Unzulänglichkeit, vor allem, da sogar NTFS das Erstellungsdatum speichert.
(Hab grade leider keine Zeit, den Artikel zu lesen, werde es aber später nachholen
Ext4 kann das bereits und btrfs wird es auch können -- es mangelt aber gegenwärtig noch am Support durch die Userspace-Tools.
Hier ein Beispiel, wie man sich die Erstellungszeit (crtime) einer Datei auf einem Ext4-Dateisystem mittels debugfs anzeigen lassen kann: (Vorsicht, root-Zugriff benötigt!)
Von Booooooooom! am Do, 26. August 2010 um 21:09 #
Naja, vielleicht haben sie sich es damals auch einfach so gedacht, das mtime == crtime ist. Mit der Änderung an dem Dateiinhalt hast du eigentlichen eine neue Datei geschaffen, und damit könnte man die mtime als crtime betrachten. Aber das ist nur so ein wirre Idee
Das ist so, weil POSIX das so vorschreibt. Sollte das eigentliche Erstellungsdatum gespeichert werden, ist das eine Erweiterung, die über POSIX hinausgeht. Das kann man kritisch sehen
Speichert BTRFS eigentlich das Erstellungsdatum einer Datei? Alle aktuellen Linux-FS' speichern lediglich das Datum der letzten Modifikation. Meiner Meinung nach eine Unzulänglichkeit, vor allem, da sogar NTFS das Erstellungsdatum speichert.
(Hab grade leider keine Zeit, den Artikel zu lesen, werde es aber später nachholen
Ext4 kann das bereits und btrfs wird es auch können -- es mangelt aber gegenwärtig noch am Support durch die Userspace-Tools.
Hier ein Beispiel, wie man sich die Erstellungszeit (crtime) einer Datei auf einem Ext4-Dateisystem mittels debugfs anzeigen lassen kann: (Vorsicht, root-Zugriff benötigt!)
# debugfs -R 'stat <'$(ls -i /home/user/example.txt | cut -d' ' -f 1)'>' /dev/sda1
...
debugfs 1.41.12 (17-May-2010)
Inode: 3722069 Type: regular Mode: 0644 Flags: 0x80000
Generation: 3873355471 Version: 0x00000000:00000001
User: 1000 Group: 100 Size: 47
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4c7678fa:73df1374 -- Thu Aug 26 16:23:54 2010
atime: 0x4c7677dd:97a25974 -- Thu Aug 26 16:19:09 2010
mtime: 0x4c7678fa:73df1374 -- Thu Aug 26 16:23:54 2010
crtime: 0x4c767736:b7d21878 -- Thu Aug 26 16:16:22 2010
Size of extra inode fields: 28
EXTENTS:
(0): 14775712
...
Nicht schön, aber selten
... Naja. zumindest mal ein Fortschritt
Naja, vielleicht haben sie sich es damals auch einfach so gedacht, das mtime == crtime ist. Mit der Änderung an dem Dateiinhalt hast du eigentlichen eine neue Datei geschaffen, und damit könnte man die mtime als crtime betrachten. Aber das ist nur so ein wirre Idee
Das ist so, weil POSIX das so vorschreibt. Sollte das eigentliche Erstellungsdatum gespeichert werden, ist das eine Erweiterung, die über POSIX hinausgeht. Das kann man kritisch sehen
>> Das kann man kritisch sehen
Durchaus. Vor allem da diese Vorgabe keinerlei Logik beherbergt.
> [...]eine Erweiterung, die über POSIX hinausgeht. Das kann man kritisch sehen
POSIX verlangt Features. Es verbietet keine, solange sich das nicht mit Anforderungen überschneidet.
Keine Einwände
Es *könnte* aber unangehm werden, sobald die ersten Anwendungen diese neuen Features vorraussetzen.