Comment trouver la date de création d’un fichier sous Linux : Guide technique complet

Linux n’expose pas nativement le temps de naissance des fichiers via la plupart des outils standard de l’espace utilisateur, mais les données sous-jacentes existent souvent — le défi est de savoir exactement où chercher et quelle version de système de fichiers et de noyau vous utilisez. Sur les systèmes de fichiers ext4, btrfs, xfs et tmpfs avec le noyau Linux 4.11+, les vrais horodatages de naissance (crtime) sont stockés dans l’inode et peuvent être récupérés via des utilitaires de bas niveau spécifiques. Sur les systèmes de fichiers ou noyaux plus anciens, vous devez utiliser une combinaison de métadonnées d’inode, de journaux système et de débogueurs spécifiques au système de fichiers pour approximer le temps de création.

Ce guide couvre toutes les méthodes fiables disponibles en 2024, y compris leurs prérequis techniques, la syntaxe exacte des commandes, les modes d’échec connus et quand chaque approche est appropriée pour l’administration de systèmes en production.

Pourquoi le temps de création de fichiers sous Linux n’est pas simple

Chaque fichier sous Linux est décrit par un inode — une structure de données stockant des métadonnées telles que les permissions, la propriété, la taille et les horodatages. La norme POSIX a historiquement défini trois horodatages :

• atime — heure du dernier accès
• mtime — heure de la dernière modification (contenu modifié)
• ctime — heure de changement de l’inode (métadonnées ou contenu modifié)

De manière critique, ctime n’est pas le temps de création. C’est l’une des idées fausses les plus courantes parmi les administrateurs migrant depuis des environnements Windows. ctime se met à jour chaque fois que les permissions changent, que la propriété change ou que le fichier est renommé — cela n’a rien à voir avec le moment où le fichier a été créé pour la première fois.

Le vrai temps de création, connu sous le nom de temps de naissance ou crtime, a été ajouté à la structure d’inode ext4 et est exposé via l’appel système statx() introduit dans le noyau Linux 4.11. Cependant, de nombreuses distributions ont fourni des outils qui ne présentaient pas ces données jusqu’à relativement récemment, ce qui explique pourquoi la confusion persiste.

Prérequis du système de fichiers et du noyau

Avant de tenter toute méthode, vérifiez votre environnement :

# Check kernel version
uname -r

# Check filesystem type for a specific path
df -T /path/to/your/file

# Check filesystem mount options
findmnt -o TARGET,FSTYPE,OPTIONS /path/to/your/file

Si vous utilisez un environnement d’Hébergement VPS, le système de fichiers sous-jacent est presque toujours ext4 ou btrfs, ce qui signifie que les données de temps de naissance sont disponibles — vous avez juste besoin des bons outils pour les afficher.

Méthode 1 : Utilisation de la commande stat (Point de départ recommandé)

La commande stat est le premier outil correct à essayer. Sur les systèmes modernes avec le noyau 4.11+ et un système de fichiers compatible, elle affichera directement le champ Birth.

stat /path/to/your/file

Exemple de sortie sur un système ext4 moderne :

  File: /home/deploy/app/config.yml
  Size: 4096            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 2883591     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  deploy)   Gid: ( 1000/  deploy)
Access: 2024-03-15 09:22:14.812345678 +0000
Modify: 2024-03-10 14:05:33.123456789 +0000
Change: 2024-03-10 14:05:33.123456789 +0000
 Birth: 2024-03-08 11:47:02.987654321 +0000

Si le champ Birth affiche - (un tiret) au lieu d’un horodatage, l’une des situations suivantes est vraie :

• Le système de fichiers ne stocke pas le temps de naissance (ext2/ext3)
• Le noyau est plus ancien que 4.11
• Le binaire stat est obsolète et n’appelle pas statx()
• Le fichier a été créé avant la mise à niveau du système de fichiers d’ext3 vers ext4

Extraction uniquement de l’horodatage de naissance de manière programmatique :

stat --format="%w" /path/to/your/file
# Returns '-' if unavailable, or ISO 8601 timestamp if available

stat --format="%W" /path/to/your/file
# Returns Unix epoch integer (0 if unavailable)

Le format %W retournant 0 est une vérification programmatique fiable pour savoir si le temps de naissance est véritablement indisponible.

Méthode 2 : Utilisation de debugfs pour les systèmes de fichiers ext4

debugfs est l’outil de bas niveau définitif pour l’inspection des inodes ext4. Il lit la structure brute de l’inode et peut exposer crtime même lorsque stat échoue en raison d’un binaire d’espace utilisateur plus ancien.

Étape 1 : Identifier le numéro d’inode de votre fichier

ls -i /path/to/your/file
# Output example: 2883591 /path/to/your/file

Étape 2 : Identifier le périphérique bloc hébergeant le système de fichiers

df /path/to/your/file
# Output shows the device, e.g., /dev/sda1 or /dev/vda1

Étape 3 : Interroger debugfs avec le numéro d’inode

sudo debugfs -R 'stat <2883591>' /dev/vda1

Remplacez 2883591 par votre numéro d’inode réel et /dev/vda1 par votre périphérique réel. La sortie inclura un champ crtime :

Inode: 2883591   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 3421897654    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 4096
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
 atime: 0x65f4a1ae:c6b5c000 -- Fri Mar 15 09:22:14 2024
 mtime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
crtime: 0x65e4b2c6:eb851400 -- Thu Mar 08 11:47:02 2024
Size of extra inode fields: 28

Note opérationnelle importante : debugfs ouvre le système de fichiers en mode lecture seule par défaut lors de l’utilisation de -R, mais vous devriez tout de même éviter de l’exécuter sur un système de fichiers très actif sans d’abord le démonter ou utiliser un instantané. Sur les Serveurs Dédiés en production, préférez toujours exécuter debugfs sur un instantané du système de fichiers ou un volume mis en veille pour éviter de lire un état d’inode incohérent.

Syntaxe alternative utilisant directement le nom de fichier :

sudo debugfs -R "stat /path/to/your/file" /dev/vda1

Notez que le chemin ici doit être relatif à la racine du système de fichiers, pas à la racine du système. Si /dev/vda1 est monté sur /, alors /path/to/your/file fonctionne tel quel.

Méthode 3 : Utilisation de xfs_db pour les systèmes de fichiers XFS

Sur les systèmes de fichiers XFS (courants sur les systèmes RHEL/CentOS/Rocky Linux), l’équivalent de debugfs est xfs_db.

# Get inode number first
ls -i /path/to/your/file

# Unmount or use read-only mode
sudo xfs_db -r /dev/sda1 -c "inode <inode_number>" -c "print"

Recherchez le champ v3.crtime dans la sortie. XFS v5 (la valeur par défaut depuis RHEL 7) stocke le temps de naissance nativement. XFS v4 ne le fait pas.

Méthode 4 : Utilisation de l’inspection de sous-volume et de fichier btrfs

Sur btrfs, stat avec un noyau moderne est suffisant et entièrement fiable. Cependant, pour une inspection plus approfondie :

sudo btrfs inspect-internal dump-tree /dev/sdb | grep -A 20 "inode ref"

Pour des besoins pratiques sur btrfs, le champ Birth de la sortie stat fait autorité.

Méthode 5 : Interrogation de statx() directement via Python

Lorsque les outils shell donnent des résultats incohérents, appeler directement le syscall statx() depuis Python fournit une réponse définitive :

import os
import stat

result = os.stat("/path/to/your/file")
# st_birthtime is available on systems where statx() returns it
if hasattr(result, 'st_birthtime'):
    import datetime
    birth = datetime.datetime.fromtimestamp(result.st_birthtime)
    print(f"Birth time: {birth}")
else:
    print("Birth time not available on this platform/filesystem")

Pour une résolution en nanosecondes plus précise, utilisez le module ctypes pour appeler statx() directement — cela est utile dans les scripts forensiques où la précision des horodatages est importante.

Méthode 6 : Recherche dans les journaux système

Lorsque le temps de naissance au niveau du système de fichiers est indisponible — par exemple, sur les systèmes de fichiers ext3 ou les fichiers antérieurs à une conversion de système de fichiers — les journaux système deviennent la solution de repli.

Recherche dans le journal systemd :

journalctl --since="2024-01-01" | grep "your_filename"

Recherche dans le syslog traditionnel :

grep "your_filename" /var/log/syslog
grep "your_filename" /var/log/messages

Recherche dans le journal d’audit (si auditd est configuré) :

sudo ausearch -f /path/to/your/file

Le sous-système d’audit est la méthode basée sur les journaux la plus fiable car il enregistre les appels système openat(), creat() et rename() avec des horodatages précis. Cependant, il doit être configuré à l’avance — vous ne pouvez pas auditer rétroactivement les événements de création de fichiers qui se sont produits avant l’activation d’auditd.

Activer l’audit de création de fichiers pour un répertoire :

sudo auditctl -w /var/www/html -p w -k web_file_creation

Cela surveille /var/www/html pour les événements d’écriture, en les étiquetant avec la clé web_file_creation pour une récupération facile.

Méthode 7 : Utilisation de ls — Comprendre ses limitations

La commande ls est fréquemment citée dans les guides comme moyen de vérifier le temps de création, mais cela nécessite une qualification importante.

ls -l --time=birth /path/to/your/file
ls -l --time=creation /path/to/your/file  # synonym on some systems

Mise en garde critique : ls --time=birth ne fonctionne que sur GNU coreutils 8.25+ et uniquement lorsque le système de fichiers et le noyau sous-jacents prennent en charge le temps de naissance. Si le temps de naissance est indisponible, ls revient silencieusement à mtime sans aucun avertissement. Ce repli silencieux est un risque opérationnel important — vous pouvez croire que vous lisez le temps de création alors que vous lisez en réalité le temps de modification.

Vérifiez toujours avec stat d’abord. Utilisez ls uniquement à des fins d’affichage, pas pour la logique scriptée.

# Safer: check stat output explicitly before relying on ls
BIRTH=$(stat --format="%W" /path/to/your/file)
if [ "$BIRTH" -eq 0 ]; then
    echo "Birth time unavailable, falling back to mtime"
    stat --format="%y" /path/to/your/file
else
    echo "Birth time: $(date -d @$BIRTH)"
fi

Comparaison des méthodes et matrice de décision

Cas limites réels et pièges

Fichier copié vs. déplacé : Lorsqu’un fichier est copié (cp), la destination obtient un nouvel inode avec un nouveau temps de naissance. Lorsqu’un fichier est déplacé dans le même système de fichiers (mv), l’inode est préservé et le temps de naissance reste inchangé. mv entre systèmes de fichiers se comporte comme cp + rm, créant un nouvel inode.

Conversion de système de fichiers d’ext3 vers ext4 : Les fichiers qui existaient avant la conversion auront un crtime de zéro dans leur inode, car ext3 n’a jamais renseigné ce champ. debugfs affichera crtime: 0x00000000:00000000. Dans ce cas, mtime au moment de la conversion est la meilleure approximation.

Docker et environnements de conteneurs : Les systèmes de fichiers de conteneurs (overlay2, aufs) peuvent ne pas propager correctement le temps de naissance. Les fichiers à l’intérieur des conteneurs peuvent afficher le temps de naissance comme l’heure de démarrage du conteneur plutôt que le temps de création réel du fichier.

Montages NFS : La disponibilité du temps de naissance dépend entièrement du système de fichiers du serveur NFS. Le client n’a pas de données de temps de naissance indépendantes.

Restauration de sauvegarde : Les fichiers restaurés depuis des archives tar obtiennent généralement un nouvel inode et donc un nouveau temps de naissance reflétant la date de restauration, pas la date de création originale. Utilisez tar --preserve-permissions et vérifiez mtime pour l’approximation la plus proche du temps de création original.

Pour les administrateurs gérant des applications web sur un VPS avec cPanel, l’intégrité des horodatages de fichiers est particulièrement importante lors des migrations — vérifiez toujours les métadonnées d’inode après une restauration depuis une sauvegarde.

Activation du support du temps de naissance : Réglage du système de fichiers

Si vous configurez un nouveau serveur et souhaitez un support garanti du temps de naissance, assurez-vous des points suivants :

Pour ext4 — vérifiez que la taille de l’inode est de 256 octets (requis pour le champ crtime) :

sudo tune2fs -l /dev/vda1 | grep "Inode size"
# Should return: Inode size: 256

Si la taille de l’inode est de 128, le temps de naissance ne peut pas être stocké. Cela nécessite un reformatage — cela ne peut pas être modifié sur un système de fichiers existant.

Créer un nouveau système de fichiers ext4 avec des inodes de 256 octets (par défaut depuis e2fsprogs 1.41) :

sudo mkfs.ext4 -I 256 /dev/vdb1

Vérifier que le noyau supporte statx() :

uname -r  # Must be >= 4.11

Lors du provisionnement d’une nouvelle infrastructure — qu’il s’agisse d’un Hébergement Web Mutualisé ou de Serveurs Dédiés bare-metal — confirmez la taille de l’inode du système de fichiers avant de déployer des applications qui dépendent des métadonnées de temps de naissance.

Liste de contrôle pratique pour déterminer le temps de création d’un fichier

Utilisez cet arbre de décision lorsque vous devez trouver la date de création d’un fichier :

• Vérifiez d’abord la version du noyau : uname -r — doit être 4.11+ pour que stat affiche Birth
• Vérifiez le type de système de fichiers : df -T /path/to/file — ext4, btrfs ou xfs v5 requis
• Exécutez stat sur le fichier : Si le champ Birth affiche un horodatage, vous avez votre réponse
• Si Birth affiche - : Exécutez debugfs (ext4) ou xfs_db (xfs) avec le numéro d’inode
• Si le système de fichiers est ext3 ou ext2 : Revenez à mtime comme meilleure approximation
• Si vous avez besoin d’une précision de niveau audit à l’avenir : Configurez auditd maintenant
• Si le fichier a été créé récemment : Vérifiez journalctl pour des entrées de journal corroborantes
• Dans les scripts : Vérifiez toujours stat --format="%W" pour 0 avant de faire confiance à la valeur
• Après des migrations ou des restaurations : Traitez le temps de naissance comme suspect ; recoupez avec mtime et les manifestes de sauvegarde

Pour les environnements où l’intégrité des fichiers et la précision des horodatages sont des exigences de sécurité — comme les applications gérant des Certificats SSL et des fichiers de clés cryptographiques — combiner auditd avec le temps de naissance au niveau du système de fichiers vous donne une approche de vérification à deux couches qui est défendable lors des audits de sécurité.

FAQ

Linux stocke-t-il toujours le temps de création des fichiers ?

Non. Seuls les systèmes de fichiers avec des inodes de 256 octets (ext4, btrfs, xfs v5) stockent le temps de naissance. ext2 et ext3 n’ont pas de champ de temps de naissance dans leur structure d’inode. Même sur les systèmes de fichiers compatibles, les fichiers créés avant une mise à niveau du système de fichiers d’ext3 vers ext4 auront un temps de naissance nul.

Quelle est la différence entre ctime et le temps de naissance sous Linux ?

ctime est l’heure de changement de l’inode — elle se met à jour chaque fois que les métadonnées du fichier (permissions, propriété, nombre de liens) ou le contenu changent. Ce n’est pas le temps de création. Le temps de naissance (crtime) est défini une fois lors de la première création du fichier et ne change jamais. De nombreux administrateurs confondent ces deux notions, ce qui conduit à des conclusions d’audit incorrectes.

Puis-je récupérer le temps de création d’un fichier après qu’il a été perdu ?

Si le champ crtime de l’inode est nul ou si le système de fichiers ne le prend pas en charge, le temps de création original ne peut pas être récupéré depuis le système de fichiers seul. Vos meilleures options sont : vérifier les journaux auditd s’ils étaient configurés, rechercher dans les journaux d’application, ou consulter les manifestes de sauvegarde qui ont enregistré les métadonnées des fichiers au moment de la sauvegarde.

Pourquoi ls --time=creation affiche-t-il une heure incorrecte ?

ls revient silencieusement à mtime lorsque le temps de naissance est indisponible, sans afficher aucun avertissement. Il s’agit d’un problème comportemental connu dans GNU coreutils. Utilisez toujours stat --format="%W" pour vérifier programmatiquement si le temps de naissance est véritablement disponible avant de vous fier à la sortie de ls.

Quelle commande donne le temps de création de fichier le plus fiable sur ext4 ?

debugfs -R 'stat <inode_number>' /dev/device est la méthode la plus fiable sur ext4 car elle lit directement la structure brute de l’inode, contournant toutes les limitations des outils de l’espace utilisateur. Pour une utilisation quotidienne sur le noyau 4.11+, stat filename avec le champ Birth est équivalent et bien plus pratique.