Fichiers systeme
On décrit ici brièvement un ensemble de fichiers produits par les systèmes d'exploitation (par opposition aux utilisateurs) pour leur usage interne. Ces fichiers ont un statut ou une fonction particulière vis-à-vis du système. Bien que certains d'entre eux puissent être reconnus par les outils d'identification comme DROID grâce à une signature numérique, et que d'autres disposent d'un type MIME et d'une documentation, la plupart doivent être identifiés par leur nom. En effet, les systèmes d'exploitation peuvent être amenés à en changer le format entre deux versions tout en en conservant le nom et la fonction. Dans une perspective de préservation numérique, on se contentera en général d'ignorer ces fichiers, bien qu'une analyse inspirée de la criminalistique numérique (digital forensics) puisse y trouver des indices utiles à la compréhension du contexte de création des données.
Cette fiche décrit uniquement les fichiers produits par les systèmes d'exploitation ; on consultera la fiche Fichiers spécifiques à une application pour les fichiers techniques dits sidecar produits par les applications pour leur bon fonctionnement.
Les fichiers et répertoires sont identifiés par leur nom ; il arrive que le nom intègre des parties variables, qui sont marquées dans les noms ci-dessous par le caractère joker "*", qui vaut 0 à n occurrences de n'importe quels caractères.
Note : comme les autres systèmes basés sur Unix (GNU/Linux, BSD, etc.), les systèmes macOS utilisent le caractère . en début de nom de fichier pour identifier un fichier ou un répertoire caché. Ces derniers sont donc invisibles par défaut pour les utilisateurs de ces systèmes mais apparaissent sur les systèmes de fichiers Windows à la suite d'une copie. Il s'agit souvent, mais pas toujours, de fichiers générés par le système ou les applications.
Le plus courant de ces fichiers est nommé Thumbs.db (QID : Q930281, PUID : fmt/682). Il s'agit d'un fichier de base de données stockant les vignettes des images d'un répertoire, permettant ainsi à l'explorateur Windows d'afficher plus rapidement un aperçu sous forme de mosaïque.
Il est souvent plus aisé de les supprimer en passant par l'invite de commande plutôt que par l'interface graphique. On pourra utiliser la ligne de commande DOS suivante pour ce faire : del /A:H Thumbs.db.
On notera également que, sous la variante du système d'exploitation Windows XP Édition Media Center, des fichiers ehthumbs.db sont créés pour stocker des vignettes de vidéos. Dans le même but, Windows Vista crée des fichiers ehthumbs_vista.db.
Il s'agit d'un fichier texte de configuration d'un répertoire, localisé à sa racine, permettant notamment de lui associer une icône ou une info-bulle, de configurer l'affichage des fichiers, etc. Ce fichier peut être ignoré/exclu.
-
[dD]esktop.ini(Windows) (QID : Q4037242) ; -
.DS_Store(Desktop Services Store) (macOS) (QID : Q307271, PUID : fmt/394) ; -
.directory(KDE/Dolphin).
En outre, on peut trouver, dans les données issues de systèmes macOS, un fichier caché à la racine du répertoire, nommé Icon\r (\r représentant le caractère carriage return) et contenant l'icône personnalisée d'un répertoire. Un fichier caché ayant la même fonction, mais pour les volumes (c.-à-d. les disques et partitions), porte le nom .VolumeIcon.icns à partir de Mac OS X.
Ces répertoires contiennent des fichiers supprimés par l'utilisateur·ice, qui n'a donc généralement pas conscience de les avoir transmis. Si leur conservation peut être utile aux chercheur·se·s, elle pose des questions éthiques qu'il n'est pas évident de résoudre.
-
$Recycle.bin/RECYCLER(Windows) ; -
.Trash/.Trashes(macOS) ; -
.Trash-*(GNU/Linux) - où la partie qui suit le tiret correspond à l'identifiant de l'utilisateur·ice qui a supprimé le(s) fichier(s).
Ces fichiers sont créés lorsqu'on supprime un fichier en cours d'utilisation par une application. Cela permet à l'application (ignorante du caractère distant du fichier) de le maintenir ouvert alors qu'il n'existe déjà plus à distance. Lorsque l'outil termine sa tâche, ce fichier temporaire est normalement supprimé, mais il peut arriver qu'il subsiste.
-
.fuse_hidden*(GNU/Linux et macOS) ; -
.nfs[numéro en hexadécimal](système de fichiers NFS).
On peut a priori les supprimer.
Outre les attributs normaux (poids du fichier, date de création, de dernière modification, etc.), certains systèmes d'exploitation utilisent, par défaut ou sous réserve d'activation, des attributs étendus permettant de stocker des métadonnées supplémentaires ne faisant pas partie du fichier lui-même (outil de création, somme de contrôle, etc.). Lorsque des fichiers disposant d'attributs étendus sont copiés sur un système de fichiers différent, il arrive que ces attributs soient inscrits dans un fichier sidecar, généralement nommé selon le nom du fichier de données.
Les systèmes d'exploitation natifs suppriment ces fichiers lorsque leur fichier de données est supprimé, mais ils peuvent subsister sans ce dernier si sa suppression a été faite sous un autre système d'exploitation.
Le plus souvent, on peut les ignorer, mais une analyse forensique pourra y trouver des informations intéressantes (par exemple, pour un fichier téléchargé depuis le web, URL, date et outil de téléchargement - voir à ce sujet ce billet). Ils sont consultables à l'aide de l'utilitaire Unix xattr ou, pour macOS, avec la commande ls -l@.
Les systèmes macOS stockent les données dans deux forks, l'une contenant les données du fichier proprement dites (data fork), l'autre (resource fork) embarquant un certain nombre d'éléments dont des attributs utiles au gestionnaire de fichiers Finder mais aussi, dans les systèmes macOS des années 1980-90, le format de fichier et l'outil de création (type/creator codes, voir à ce propos cet article) et éventuellement toutes sortes de contenus graphiques ou audiovisuels nécessaires à l'utilisation du contenu. Ainsi, l'atome moov de certains anciens fichiers Quicktime était stocké dans la resource fork et, si cette dernière n'est pas récupérée, le contenu peut s'avérer illisible - voir à ce propos cet article.
Lorsque ces données devaient être transférées sur d'autres systèmes de fichiers, il était nécessaire de transmettre les deux forks ensemble. Plusieurs formats ont été créés pour cela : MacBinary, BinHex et AppleSingle (type MIME : application/applefile, PUID : fmt/967 et fmt/968) qui réunissent en un seul fichier les deux forks.
En complément, le format AppleDouble (type MIME : multipart/appledouble, PUID : fmt/966 et fmt/503) enregistre la resource fork et les attributs du fichier dans un fichier distinct, caché, dont le nom commence par « ._ » suivi par le nom du fichier de données auquel il est associé. Les fichiers AppleDouble sont parfois créés dans un répertoire caché, situé dans le répertoire contenant les fichiers de données, nommé .AppleDouble ou __MACOSX. L'utilitaire macOS dot_clean permet de fusionner les fichiers contenant la data fork et la resource fork.
À partir de Mac OS X, la pratique de placer des ressources nécessaires au fonctionnement des contenus dans la resource fork est déconseillée, cette dernière n'étant plus utilisée que pour les attributs étendus.
Le système de fichiers NTFS permet de créer des flux alternatifs à des fichiers. L'usage attendu était le même que celui des resource forks mis en place sur les systèmes macOS antérieurs à OS X, mais, du fait du caractère presque invisible des données dans l'explorateur de fichiers, ces flux alternatifs ont été utilisés pour produire des logiciels malveillants. On peut néanmoins les afficher à l'aide de la commande dir /R dans l'invite de commande. Lors d'une copie vers un autre système de fichiers, ces données peuvent apparaître comme un fichier à part, nommé de la façon suivante : [nom du fichier maître]:[attribut]. De ce fait, il arrive que des fichiers Thumbs.db:encryptable apparaissent sur certains supports.
Ces fichiers d'un type particulier ne sont pas à proprement parler des fichiers système - ils peuvent avoir été créés volontairement par l'utilisateur·ice. Il s'agit de pointeurs vers un fichier ou un répertoire accessible à un autre emplacement (mais ils peuvent également contenir des paramètres à passer à l'application cible). Il est possible d'en lire le contenu pour extraire le chemin du fichier cible sur le système de fichiers d'origine, en particulier si ce fichier cible n'est plus accessible à la suite d'une copie. Leur nom et leur identification dépendent du système d'exploitation qui les a créés.
- Sous Windows ils sont appelés « raccourcis », ils sont repérables à leur extension
.lnk(PUID : x-fmt/428, type MIME non officielapplication/x-ms-shortcut). - Leurs équivalents sous GNU/Linux sont les liens symboliques et les liens physiques. Leur identification est actuellement complexe puisque leur nommage est totalement libre et qu'ils ne disposent pas actuellement (janvier 2025) d'entrée dans le registre PRONOM.
Ce répertoire contient des informations utiles à l'outil de restauration du système. Certains fichiers qu'il contient, tel le fichier IndexerVolumeGuid, peuvent se retrouver dans les données livrées. Il n'y a pas, à notre connaissance, d'information utile à en tirer.
Ce fichier est créé afin d'accélérer des recherches dans les répertoires avec le gestionnaire de fichiers Finder. Sa suppression ne pose pas de problème et il ne contient pas d'information significative.
Ce fichier est créé par le gestionnaire de fichiers Finder (macOS) pour conserver le chemin vers une application devant ouvrir par défaut le répertoire.
Le protocole AFP est utilisé par les systèmes macOS pour partager des fichiers sur le réseau. Il peut générer les fichiers ou répertoires suivants :
- Fichier
.apDisk(informations liées aux répertoires partagés) ; - Répertoire
.TemporaryItems/Temporary Items/._Temporary Items(données temporaires créées au moment de la copie / du déplacement de fichiers) ; - Répertoire
Network Trash Folder(corbeille).