Dates attachées à un fichier

Arbiel · Le 20/02/2017, à 18:59

Bonsoir à tous

Je voudrais savoir quelles dates sont attachées à un fichier, et plus exactement si la date de création d'un fichier est enregistrée avec dans son inode (je veux dire par là que je voudrais retrouver la date du premier enregistrement des données, et non pas celle de l'enregistrement de ses "meta-données" dans le répertoire).

man ls a écrit :

…
-c with -lt: sort by, and show, ctime (time of last modification of
file status information) with -l: show ctime and sort by name
otherwise: sort by ctime, newest first
…
--time=WORD
with -l, show time as WORD instead of modification time: atime
-u, access -u, use -u, ctime -c, or status -c; use specified
time as sort key if --sort=time

Cet extrait indique ctime, atime, access (?), status (?).

Merci d'avance.

Arbiel

serged · Le 21/02/2017, à 08:24

La date de première création est assez subjective.

Par exemple, on peut "créer" un nouveau fichier, copier avec une modification dans un nouveau fichier, effacer l'ancien et renommer le nouveau avec le nom de l'ancien...
Ici la date de création sera aussi la date de la dernière modification.

Arbiel · Le 21/02/2017, à 16:38

D'accord, je comprends bien que la "date de création" d'un fichier peut être interprétée de diverses manières. J'ai bien constaté que la date de création d'un fichier par copier/coller avec Nautilus est celle du fichier origine et non la date de la copie elle-même.

Mais je voudrais savoir si la date de création, qu'elle résulte d'une copie de fichier ou de la création ex nihilo, est conservée quelque part afin de pouvoir la comparer à la date de la dernière modification. En d'autres termes, savoir si un fichier a été modifié ultérieurement à sa création.

Arbiel

Ferod · Le 21/02/2017, à 22:44

stat nom_fichier

te donnera quelques dates : date de dernier accès, de modification et de changement. Quand à savoir à quoi correspondent ces dates je ne sais pas. Il faudrait chercher plus sur le net.

  Fichier : '10. giggle.gif'
   Taille : 1021      	Blocs : 8          Blocs d'E/S : 4096   fichier
Périphérique : 803h/2051d	Inœud : 41419282    Liens : 1
Accès : (0674/-rw-rwxr--)  UID : ( 1000/sebastien)   GID : ( 1000/sebastien)
Accès : 2015-12-20 20:16:40.015433508 +0100
Modif. : 2007-11-24 20:27:32.000000000 +0100
Changt : 2014-03-22 10:23:40.281193714 +0100
  Créé : -

bruno · Le 22/02/2017, à 09:16

Bonjour,

À ma connaissance il n'y a pas de "date de création" enregistrée. Il y a trois horodatages pour les fichiers :

- atime : date dur dernier accès (ouverture du fichier, affichage avec cat, grep, tail, etc.) ; visible avec ls -lu

- mtime : date de modification du contenu du fichier (données) ; visible avec ls -l

- ctime : date de "changement" du fichier : toute modification des données, changement des droits ou du propriétaire/groupe, déplacement sur un autre système de fichiers ; visible avec ls -lc

Ce sont bien ces trois valeurs que montre la sortie de stat dans l'exemple précédent.

Dernière modification par bruno (Le 22/02/2017, à 09:21)

Arbiel · Le 22/02/2017, à 11:19

Bonjour

Merci pour ces informations.

L'exemple donné par Ferod montre cependant l'existence d'une date de création, que stat ne sait pas retrouver, ou qui n'est plus renseignée.

Arbiel

bruno · Le 22/02/2017, à 12:16

Effectivement, en cherchant un peu je suis tombé sur cette discussion (en anglais) :

http://stackoverflow.com/questions/1484 … n#14842384

Il semble que l'on puisse récupérer la date de création d'un inode sur un système de fichier ext4 par un moyen détourné (avec debugfs).

stat ne renvoie pas la date de création car la fonction n'est pas implémentée dans le noyau : https://lkml.org/lkml/2010/7/22/249

Arbiel · Le 22/02/2017, à 12:31

Merci beaucoup. J'enregistre l'information.

Arbiel · Le 22/02/2017, à 12:45

Mais, malheureusement, cela ne fonctionne pas vraiment pour des fichiers enregistrés sur des partitions chiffrées. Ma / est chiffrée, et j'ai testé sur /etc/fstab

remi@remi-Vostro-3550:~$ ls -i /etc/fstab
11113 /etc/fstab
remi@remi-Vostro-3550:~$ debugfs -R 'stat <11113>' /dev/mapper/victor-root
debugfs 1.42.9 (4-Feb-2014)

Inode: 11113   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 510910978    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 3460
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x58ac8710:78fda88c -- Tue Feb 21 19:29:36 2017
 atime: 0x58ac8711:6f74401c -- Tue Feb 21 19:29:37 2017
 mtime: 0x58ac8710:70686490 -- Tue Feb 21 19:29:36 2017
crtime: 0x58ac8710:6c97d494 -- Tue Feb 21 19:29:36 2017
Size of extra inode fields: 28
EXTENTS:
(0):384549

Mon fichier /etc/fstab ne tombe pas de la dernière pluie !. C'est a priori une erreur que les dates soient celles du dernier démarrage (mais j'ai de plus l'impression d'avoir redémarré mon PC ce matin).

Arbiel

Edit

J'ai dû modifié hier mon fichier fstab. un test sur le fichier /etc/crypttab donne des résultats légèrement meilleurs, mais néanmoins pas convaincants

remi@remi-Vostro-3550:~$ ls -i /etc/crypttab
11705 /etc/crypttab
remi@remi-Vostro-3550:~$ debugfs -R 'stat <11705>' /dev/mapper/victor-root
debugfs 1.42.9 (4-Feb-2014)
remi@remi-Vostro-3550:~$ 

Inode: 11705   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 1204064025    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 2329
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x580b7fff:8c8d7ad4 -- Sat Oct 22 17:04:31 2016
 atime: 0x58ac0f0b:5e50170c -- Tue Feb 21 10:57:31 2017
 mtime: 0x580b7fff:7f3382dc -- Sat Oct 22 17:04:31 2016
crtime: 0x580b7fff:7d4b3adc -- Sat Oct 22 17:04:31 2016
Size of extra inode fields: 28
EXTENTS:

Je reste surpris par ces résultats. En particulier, la date de dernier accès à crypttab n'est pas celle du dernier accès à fstab, comme on pourrait s'y attendre. La date de création des deux fichiers est antérieure à octobre 2016. Je viens de vérifier que je n'utilise pas l'option "noatime" pour le montage de la racine

remi@remi-Vostro-3550:~$ grep victor-root /etc/fstab
/dev/mapper/victor-root /               ext4    errors=remount-ro 0       1
remi@remi-Vostro-3550:~$

et

remi@remi-Vostro-3550:~$ stat /etc/fstab
  Fichier : «/etc/fstab»
   Taille : 3460      	Blocs : 8          Blocs d'E/S : 4096   fichier
Périphérique : fc13h/64531d	Inœud : 11113       Liens : 1
Accès : (0644/-rw-r--r--)  UID : (    0/    root)   GID : (    0/    root)
Accès : 2017-02-21 19:29:37.467472391 +0100
Modif. : 2017-02-21 19:29:36.471472420 +0100
Changt : 2017-02-21 19:29:36.507472419 +0100
  Créé : -
remi@remi-Vostro-3550:~$

alors que je viens d'y accéder pour en extraire la ligne de montage de /.

Dernière modification par Arbiel (Le 22/02/2017, à 16:14)

bruno · Le 22/02/2017, à 17:23

Alors là je n'en sais rien…

Je pense que le souci vient du fait qu'il y a un système de fichiers sous-jacent (probablement ext4) et un système de fichier au dessus chiffré. Comment sont gérés les méta-données d'un inode sur les deux systèmes de fichiers ? Je n'en ai aucune idée…

Il faudrait voir avec un debugfs sur le système de fichiers sous-jacent : debugfs … … /dev/sd** plutôt que /dev/mapper/***

Est-ce que ecryptfs-stat (pas sûr de la commande) sort quelque chose ?

Arbiel · Le 23/02/2017, à 11:55

Bonjour

ecryptfs ne me semble pas concerné. D'après ce que j'ai compris, ce système de fichiers chiffre les documents un à un et inscrit les metadonnées nécessaires en début de fichier

man ecryptfs a écrit :

eCryptfs is a POSIX-compliant enterprise-class stacked cryptographic
filesystem for Linux. It is derived from Erez Zadok's Cryptfs, imple‐
mented through the FiST framework for generating stacked filesystems.
eCryptfs extends Cryptfs to provide advanced key management and policy
features. eCryptfs stores cryptographic metadata in the header of each
file written, so that encrypted files can be copied between hosts; the
file will be decryptable with the proper key, and there is no need to
keep track of any additional information aside from what is already in
the encrypted file itself. Think of eCryptfs as a sort of "gnupgfs."

Autant que j'aie compris le fonctionnement du chiffrement par dm-crypt, c'est la partition vue comme une suite d'octets qui est chiffrée. Les informations qui y sont contenues ne sont pas interprétées et les métadonnées n'ont pas lieu d'être modifiées dans le chiffrement/déchiffrement.

Mais passons. De tout cela il résulte que la date de création d'un fichier n'est pas disponible.

Je te remercie de t'être penché sur ma question.

Et cette discussion m'a soulevé d'autres questions relatives aux liens physiques. Mais j'y reviendrai ultérieurement.

Arbiel

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 20/02/2017, à 18:59

Dates attachées à un fichier

#2 Le 21/02/2017, à 08:24

Re : Dates attachées à un fichier

#3 Le 21/02/2017, à 16:38

Re : Dates attachées à un fichier

#4 Le 21/02/2017, à 22:44

Re : Dates attachées à un fichier

#5 Le 22/02/2017, à 09:16

Re : Dates attachées à un fichier

#6 Le 22/02/2017, à 11:19

Re : Dates attachées à un fichier

#7 Le 22/02/2017, à 12:16

Re : Dates attachées à un fichier

#8 Le 22/02/2017, à 12:31

Re : Dates attachées à un fichier

#9 Le 22/02/2017, à 12:45

Re : Dates attachées à un fichier

#10 Le 22/02/2017, à 17:23

Re : Dates attachées à un fichier

#11 Le 23/02/2017, à 11:55

Re : Dates attachées à un fichier

Pied de page des forums