Quel est le concept de création d'un fichier avec zéro octet sous Linux?
Si je fais ce qui suit:
touch /tmp/test
puis effectuer
ls -la /tmp/
J'ai pu voir le fichier test avec octets dans le répertoire.
Mais comment le système d'exploitation gère-t-il un concept de octets. Si je le dis en termes simples:
0 octet n'est pas du tout de mémoire, donc rien n'est créé.
La création d'un fichier, doit ou doit nécessiter au moins une certaine mémoire, droite?
Un fichier est (à peu près) trois choses distinctes:
- Un "inode", une structure de métadonnées qui garde la trace de qui détient le fichier, les autorisations et une liste de blocs sur le disque qui contiennent réellement les données.
- Une ou plusieurs entrées de répertoire (les noms de fichiers) qui pointent vers cet inode
- Les blocs de données eux-mêmes
Lorsque vous créez un fichier vide, vous créez uniquement l'inode et une entrée de répertoire pointant vers cet inode. Idem pour les fichiers épars (dd if=/dev/null of=sparse_file bs=10M seek=1).
Lorsque vous créez des liens physiques vers un fichier existant, vous créez simplement des entrées de répertoire supplémentaires qui pointent vers le même inode.
J'ai simplifié les choses ici, mais vous voyez l'idée.
touch créera un inode, et ls -i ou stat affichera des informations sur l'inode:
$ touch test
$ ls -i test
28971114 test
$ stat test
File: ‘test’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fc01h/64513d Inode: 28971114 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/1000) Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
Birth: -
Notez que test utilise 0 bloc. Pour stocker les données affichées, l'inode utilise quelques octets. Ces octets sont stockés dans la table d'inode. Regardez la page ext2 pour un exemple d'une structure inode .
ls (ou bien, l'appel système stat(2)) vous indique la taille de contents du fichier. La quantité d'espace dont le système de fichiers a besoin pour la comptabilité ne fait pas partie de cela, et en tant que détail d'implémentation, ce n'est pas quelque chose que les programmes en général devraient se soucient ou même connaissent. Rendre les détails de l'implémentation visibles rendrait l'abstraction du système de fichiers moins utile.
Le fichier lui-même n'occupe aucun espace, mais le système de fichiers le fait, stockant le nom de fichier, l'emplacement, les droits d'accès à celui-ci, etc.
Réponse simple: Parce que c'est défini de cette façon.
Réponse plus longue: elle est définie de cette façon car certaines opérations sont conceptuellement plus simples:
- Si un fichier contient 20 lettres "A" et que vous supprimez tous les "A", le fichier raccourcira de 20 octets. La même opération sur un fichier composé uniquement de "AAAAAAAAAAAAAAAAAAAA" devrait traiter le cas particulier d'un fichier en voie de disparition.
- Plus concrètement, la suppression de la dernière ligne d'un fichier texte devrait être placée dans un boîtier spécial.
- Les éditeurs de texte qui effectuent régulièrement une sauvegarde auraient besoin d'un code de cas spécial pour faire face à la situation où l'utilisateur pourrait supprimer la dernière ligne, aller déjeuner, puis revenir et ajouter une autre ligne. D'autres complications surviennent si d'autres utilisateurs ont créé un fichier avec ce nom dans l'intervalle.
Vous pouvez faire plus de choses: * Les fichiers journaux d'erreurs ont tendance à être créés vides, à remplir si et seulement si une erreur se produit. * Pour savoir combien d'erreurs se sont produites, vous comptez le nombre de lignes dans les fichiers journaux. Si le fichier journal est vide, le nombre d'erreurs est nul, ce qui est parfaitement logique. * Parfois, vous voyez des fichiers où tout le texte pertinent se trouve dans le nom du fichier, par exemple this-is-the-logging-directory. Cela empêche les administrateurs exagérés de supprimer les répertoires vides après l'installation et empêche également les bogues où un programme ou un utilisateur crée accidentellement un fichier dans lequel le programme souhaiterait voir un répertoire plus tard. Le programme git (et d'autres) a tendance à ignorer les répertoires vides, et si un projet/administrateur/utilisateur veut avoir un enregistrement que le répertoire existe même s'il n'a pas (encore) de contenu utile, vous pouvez voir un fichier vide nommé empty ou empty.directory.
Aucune opération ne devient plus compliquée:
- Concaténation de fichiers: il s'agit simplement d'un no-op avec un fichier vide.
- Recherche d'une chaîne dans un fichier: ceci est couvert par le cas standard de "si le fichier est plus court que le terme de recherche, il ne peut pas contenir le terme de recherche".
- Lecture à partir du fichier: les programmes doivent gérer la fin du fichier avant d'obtenir ce qu'ils attendaient, donc encore une fois le cas d'un fichier de longueur nulle n'implique pas de réflexion supplémentaire pour le programmeur: il va juste toucher la fin de -fichier depuis le début.
Dans le cas des fichiers, l'aspect "il y a un fichier enregistré quelque part" (inode et/ou nom de fichier) vient en tête des considérations ci-dessus, mais les systèmes de fichiers ne le feraient pas si les fichiers vides étaient inutiles.
En général, toutes les raisons ci-dessus, à l'exception de celles liées aux noms de fichiers, s'appliquent aux séquences. Plus particulièrement aux chaînes, qui sont des séquences de caractères: les chaînes de longueur nulle sont courantes à l'intérieur des programmes. Les chaînes sont généralement interdites au niveau de l'utilisateur si elles n'ont pas de sens: un nom de fichier est une chaîne et la plupart des systèmes de fichiers n'autorisent pas une chaîne vide comme nom de fichier; en interne, lors de la création de noms de fichiers à partir de fragments, le programme peut très bien avoir une chaîne vide comme l'un des fragments.
En utilisant l'analogie la plus simple:
Comparons un fichier avec, disons, un verre d'eau.
'touch/tmp/test' ressemble beaucoup à la création d'un verre vide, sans eau. Le verre est vide, sa taille est donc nulle. Mais le verre existe.
Dans le langage des systèmes de fichiers, le verre est les métadonnées, tandis que le contenu du verre est les données. Les métadonnées contiennent toutes sortes de choses, comme mentionné dans les articles précédents.
Des fichiers de taille zéro peuvent être utiles. Un exemple est de les utiliser comme fil d'Ariane, où sa simple existence peut être utilisée pour indiquer une sorte d'état (c'est-à-dire, si le fichier existe: alors faites quelque chose; sinon: ignorez).
Pensez-y de cette façon: disons qu'un programme suit les requêtes SQL envoyées à votre serveur. Le programme souhaite indiquer qu'il enregistre les demandes dans un fichier en texte brut, mais aucune demande n'a encore été enregistrée. À quoi cela devrait-il ressembler? Je dirais que ce devrait être un fichier de taille nulle à /var/log/acme-sql-server/queries.log. De cette façon, vous pouvez déterminer quand la journalisation a commencé (l'heure de création du fichier), quand il a été mis à jour pour la dernière fois (c'est-à-dire quand il a été créé), combien de requêtes ont été enregistrées (nombre de sauts de ligne dans le fichier = 0) et qui fait la journalisation (Acme SQL Server). Pour des cas comme celui-ci, il est utile d'avoir le concept d'un fichier vide qui existe néanmoins à un emplacement particulier.