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

et ensuite effectuer

ls -la /tmp/

Je pouvais voir le testfichier avec 0 octets dans le répertoire.

Mais comment le système d’exploitation gère-t-il un concept de 0 octet . Si je le dis en termes profanes:

0 octet n'est pas du tout une mémoire, donc rien n'est créé.

La création d'un fichier doit ou doit au moins nécessiter une certaine mémoire, n'est-ce pas?

Un fichier est constitué (en gros) de trois choses distinctes:

• Un "inode", une structure de métadonnées qui garde la trace du propriétaire du fichier, des autorisations et d'une liste de blocs sur le disque contenant 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 fragmentés ( 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.

touchcréera un inode , et ls -iou stataffichera 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: -

Avis qui testutilise 0 blocs. Pour stocker les données affichées, l'inode utilise des octets. Ces octets sont stockés dans la table inode. Regardez la page ext2 pour un exemple de structure inode .

ls(ou bien, l' stat(2)appel système) vous indique la taille du contenu du fichier. L'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 soucier ou même connaître. Rendre les détails de la mise en œuvre visibles rendrait l'abstraction du système de fichiers moins utile.

Le fichier lui-même n'occupe aucun espace, contrairement au système de fichiers, qui enregistre le nom du fichier, son emplacement, ses droits d'accès, etc.

Réponse simple: Parce que c'est défini comme ça.

Réponse plus longue: il est défini ainsi car certaines opérations sont conceptuellement plus simples:

• Si un fichier contient 20 lettres "A" et que vous supprimez tous les "A", le fichier sera alors 20 octets plus court. La même opération sur un fichier constitué uniquement de "AAAAAAAAAAAAAAAAAAAAAA" devrait traiter du cas particulier d'un fichier en train de disparaître.
• Plus concrètement, la suppression de la dernière ligne d'un fichier texte nécessiterait une casse spéciale.
• Les éditeurs de texte qui effectuent régulièrement une sauvegarde auraient besoin d'un code de cas spécial pour permettre à l'utilisateur de supprimer la dernière ligne, d'aller déjeuner, puis de revenir et d'ajouter une autre ligne. Des complications supplémentaires surviennent si d’autres utilisateurs créent un fichier portant ce nom entre-temps.

Vous pouvez faire plus de choses: * Les fichiers journaux d’erreur sont généralement 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 égal à zéro, ce qui est parfaitement logique. * Parfois, vous voyez des fichiers contenant tout le texte pertinent dans le nom du fichier, par exemple ou .this-is-the-logging-directory . Cela empêche les administrateurs trop exigeants de supprimer les répertoires vides après l'installation, ainsi que les erreurs dans lesquelles un programme ou un utilisateur crée accidentellement un fichier dans lequel le programme souhaite voir un répertoire ultérieurement. Le gitprogramme (et d’autres) ont tendance à ignorer les répertoires vides. Si un projet / administrateur / utilisateur souhaite disposer d’un enregistrement attestant que le répertoire existe même s’il n’a pas (encore) de contenu utile, vous pouvez voir un fichier vide nomméemptyempty.directory

Aucune opération ne devient plus compliquée:

• Concaténer des fichiers: il s’agit simplement d’une opération non-op avec un fichier vide.
• Rechercher une chaîne dans un fichier: ceci est couvert par la casse standard de "si le fichier est plus court que le terme recherché, il ne peut pas contenir le terme recherché".
• Lecture du fichier: les programmes doivent gérer la fin du fichier avant d’obtenir ce à quoi ils s’attendaient. Le cas d’un fichier de longueur nulle n’implique donc pas une réflexion supplémentaire du programmeur: il ne fera que taper à la fin du fichier. -file 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) s'ajoute aux 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 dans les programmes. Les chaînes sont généralement interdites au niveau 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 en tant que nom de fichier; en interne, lors de la création de noms de fichiers à partir de fragments, le programme peut très bien contenir une chaîne vide.

En utilisant la plus simple analogie:

Comparons un fichier avec, par exemple, un verre d'eau.

'touch / tmp / test' revient à créer un verre vide, sans eau. Le verre est vide, sa taille est donc zéro. Mais le verre existe.

Dans le langage des systèmes de fichiers, le verre est la méta-donnée, alors que le contenu du verre est la donnée. Les méta-données contiennent toutes sortes de choses comme mentionné dans les posts précédents.

Les fichiers de taille zéro peuvent être utiles. Un exemple consiste à les utiliser comme un 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 veut indiquer qu'il enregistre les demandes dans un fichier texte, mais aucune demande n'a encore été enregistrée. À quoi cela devrait-il ressembler? Je dirais que ce devrait être un fichier de taille zéro à /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 nouvelles lignes dans le fichier = 0) et qui effectue la journalisation. (Acme SQL Server). Dans de tels cas, il est utile d’avoir le concept de fichier vide qui existe néanmoins à un emplacement particulier.