dossier ou répertoire? Le sujet est résolu

[tony]

salut,
Pour répondre à ma question j'ai interrogé internet et peut-être la meilleure approche que j'ai trouvée est ici: https://the.hosting/fr/help/dossier-ou- ... sous-linux

Je rebondis sur une discussion ayant trait au départ à la commande "dd": viewtopic.php?t=3788

..........
Je pense que si l'utilisateur ne sait pas faire la différence entre disque, partition, système de gestion de fichiers, et entre un dossier et un répertoire,
...........

Je raisonne par analogie, donc avec des limites, mais bon, faute de mieux:

1- Répertoire : comme un répertoire téléphonique il ne contient qu'un minimum de renseignements permettant de trouver le chemin pour entrer en contact avec la cible: /home/, /usr/ etc sont des répertoires
2- dossier: contient des fichiers avec en général beaucoup de renseignements qui n'ont pas pour but d'identifier, mais de fournir diverses informations sur un sujet ou plusieurs: ~/.profile, fichiers de configuration etc..., . Donc /home/<user>/ devrait être un dossier puisqu'il contient à la fois des sous-répertoires et des fichiers. Or il me semble bien qu'il s'agit d'un répertoire, cf PS, du moins en anglais. Ainsi en Vf puis en Vo:

Code : Tout sélectionner

~$ file /home/<mmas>/
bash: mmas: Aucun fichier ou dossier de ce type  ---> dossier (folder)

~$ file /home/mmas/
/home/mmas/: directory  ---> répertoire

PS: j'ai rencontré 2 façons de noter un répertoire: /rep/ (rare) ou /rep ( très courant). Je suppose que /rep/ indique qu'il s'agit de "quelque chose" qui contient "autre chose", donc un répertoire ou un dossier. Ainsi en autocomplétion:

Code : Tout sélectionner

~$ cd /home/
~$ cd /home/mmas/ ---> traité comme un répertoire malgré la présence de fichiers 

mais:

Code : Tout sélectionner

~$ echo $PWD
/home/mmas

[diesel]

A ma connaissance, dans un système linux, dossier ou répertoire, c'est la même chose.

La hiérarchie est la suivante :

- support de stockage (disque, SSD, clé USB, mémoire centrale),
- table de partition et partitions (si besoin, ce n'est pas obligatoire),
- système de fichier (ext4, VFAT, ntfs...),
- répertoire ou dossiers (dont, sur un système linux /, le répertoire racine),
- fichiers.

Et sous windows ou macos, c'est pareil. Seules les appellations peuvent changer.

Amicalement.

Jean-Marie

[tony]

A ma connaissance, dans un système linux, dossier ou répertoire, c'est la même chose.
......

je me souviens d'un intervenant, @pascalhambourg je crois, qui reprenait les ceusses qui parlaient de dossier au lieu de répertoire. J'aurais dû lui poser la question du pourquoi.

[diesel]

Dans le temps... (années 70 et 80 ; ça ne nous rajeunit pas ), on parlait de "directory", ce qui se traduit par "annuaire" ou "répertoire".

C'est d'ailleurs plus juste que dossier.

En effet, dans un système de fichiers, un répertoire ne contient pas au sens strict les fichiers, il ne fait que les référencer, ce qui est bien le rôle d'un répertoire. Le seul qui contient réellement les fichiers, c'est le support d'information (le disque ou ssd ou mémoire) dans une série pas forcement consécutive de clusters (blocs). Tout le reste : partitions, système de fichiers, répertoires, ne sont que des outils pour rendre plus pratique l'accès aux informations contenues dans les fichiers. Et c'est tout aussi vrai dans windows ou macos.

Ainsi, l'appellation "dossier", faisant référence à un dossier carton qui, lui, contient physiquement les documents, est formellement abusive.

Pour la petite histoire, sur mon système debian cinnamon, le gestionnaire de fichiers Nemo parle, lui, de dossiers pour désigner les répertoires. Et si je frappe "touch toto", il me dit que toto est un "empty document" alors qu'il n'a rien de "bureautique", ni dans la terminaison (.ods par exemple), ni dans le contenu et qu'il pourrait très bien être un fichier de données brutes non encore rempli. Va-t-il falloir aussi ouvrir le débat "document" contre "fichier" ?

Va comprendre, Charles ?

Amicalement.

Jean-Marie

[MicP]

Bonjour

Dans un système de gestion de fichiers,
un répertoire (directory) est un type de fichier qui permet d'accéder à d'autres fichiers (qui peuvent aussi être des fichiers de type répertoire)

Un système de gestion de fichiers (file system) est le résultat d'un formatage (généralement d'une partition d'un disque)

On ne peut monter (greffer dans le système de gestion de fichiers racine) qu'un autre système de gestion de fichiers
une partition non formatée ne pourra jamais être montée (pas de système de fichiers existants => pas d'bras, pas de chocolats)
et un disque ne peut pas être monté pour la même raison, et pourtant, on voit très souvent écrit : "formater un disque", "monter un disque", "monter une partition", etc.

voir le retour de man mount :

Code : Tout sélectionner

MOUNT(8)                                         System Administration                                         MOUNT(8)

NAME
       mount - mount a filesystem
…

=======

Dans l'interface graphique d'un environnement de bureau,
une icône (avec une image représentant un dossier) peut être utilisée pour permettre l'accès à :
- un fichier,
- un fichier de type répertoire,
- un fichier compressé,
- une fenêtre (par ex. Accessibilité, Putty, 7.Zip) dans laquelle on trouvera d'autres icônes,
- n'importe quoi d'autre.

Si certaines icônes (avec une image représentant un dossier) permettent d'accéder à un répertoire existant dans un système de fichiers, ce répertoire n'aura pas forcément le même nom que l'icône.
Par exemple, l'icône nommée Bureau qui permet en fait d'accéder au répertoire ~/Desktop sur certains systèmes.
Certaines icônes (avec une image représentant un dossier) qui sont visibles dans l'interface graphique ne correspondent à aucun répertoire (ou fichier de n'importe quel type) existant dans un système de gestion de fichiers.

[tony]

.........

Dans l'interface graphique d'un environnement de bureau,
une icône représentant un dossier peut être utilisée pour permettre l'accès à :
- un fichier,
- un fichier de type répertoire,
- un fichier compressé,
- une fenêtre (par ex. Accessibilité, Putty, 7.Zip) dans laquelle on trouvera d'autres icônes,
- n'importe quoi d'autre.

Si certaines icônes (avec une image représentant un dossier) permettent d'accéder à un répertoire existant dans un système de fichiers, ce répertoire n'aura pas forcément le même nom que l'icône.
Par exemple, l'icône nommée Bureau qui permet en fait d'accéder au répertoire ~/Desktop sur certains systèmes.
Certaines icônes (avec une image représentant un dossier) qui sont visibles dans l'interface graphique ne correspondent à aucun répertoire (ou fichier de n'importe quel type) existant dans un système de gestion de fichiers.

donc si je comprends bien le mot dossier n'est employé que pour désigner une icône qui représente un dessin symbole de l'objet réel appelé couramment un dossier. Donc dossier = pictogramme et c'est tout. À ce moment là j'aurais finalement compris ce qu'est un dossier. Sinon ..... . Le manuel en Vf n'a pas l'air de s'en soucier, ou alors j'interprète mal la sortie "Aucun fichier ou dossier de ce type", à moins qu'il tienne compte des icônes présentes dans le système? Ça m'étonnerait car il aurait dû ajouter le mot "répertoire" à sa liste.

[MicP]

… donc si je comprends bien le mot dossier n'est employé que pour désigner une icône qui représente l'objet réel appelé couramment un dossier. Donc dossier = pictogramme et c'est tout. …

Oui, c'est très confus quand on parle d'interface graphique, et il peut y avoir n'importe quelle image dessinée sur une icône.
Un dessin de dossier sur une icône ne veut pas forcément dire qu'en cliquant sur cette icône on va pouvoir accéder à un répertoire existant dans un système de gestion de fichiers.

Dans l'interface graphique d'un système windows, les disques C:\ D:\ E:\ ne sont pas forcément de vrai disques qui seraient accessibles au système.
C:\ D:\ et E:\ peuvent en réalité être des partitions du même disque ou des répertoires compressés, ou d'autres choses.

Je cite Windows parce que c'est facilement vérifiable et que beaucoup connaissent ce système d'exploitation,
mais c'est un peu pareil pour toutes les interfaces graphiques dont le but est de simplifier tout ça pour l'utilisateur.

[tony]

Ok, maintenant c'est clair.

Merci à diesel et MicP

[piratebab]

N'oubliez pas que dans un système UNIX, donc linux, tout est fichier :)

[tony]

je reviens sur ce sujet car je ne comprends pas pourquoi un répertoire avec des fichiers, donc de l'information, est encore considéré comme un répertoire. Je me base sur la définition d'un répertoire vue ici: https://www.linfo.org/directory.html

When a file is created, it is assigned both a name and an inode number, which is an integer that is unique within the filesystem. Both the file names and their corresponding
inode numbers are stored as entries in the directory that appears to the user to contain the files. That is, the directory associates file names with inodes.

Le contenu d'un fichier n'a pas l'air de rentrer dans cette définition. Donc ce qu'on appelle "fichier" n'est en fait qu'un nom de fichier, pas le fichier physique dont on peut évaluer le "volume" avec par exemple:

Code : Tout sélectionner

~$ du -h .bashrc  
├── .bashrc
8,0K	.bashrc

Donc l'espace disque de 8.0K stocke le contenu du fichier .bashrc. Il est quelque part sur le disque et lorsque je fais "less .bashrc" le répertoire indique à la commande où de trouve le fichier réel, physique, qu'elle doit lire et afficher.

Conclusion: le répertoire qui montre des fichiers ne les contient pas, il affiche juste leur nom. Il reste bien un répertoire.

Est-ce que tout ça fait sens ou bien est-ce pure élucubration?

PS: ce que je trouve trompeur c'est que lorsqu'on regarde dans l'onglet "propriétés" (clic droit) ou qu'on utilise la commande "du", le "volume" de données d'un répertoire inclus, si je ne dis pas de bêtise, le contenu des fichiers cités dans ce répertoire. ( finalement normal pour la commande "du" )

[diesel]

Comme je te l’ai dit en #4, un répertoire ne contient pas les fichiers. Tout ce qu’il contient, c’est le nom du fichier et un numéro d’inode qui est un pointeur vers un espace de stockage du support d’information où se trouve le début des donnees du fichier. Ensuite, les inodes sont chaînés pour trouver la suite des données si celles-ci ne tiennent pas sur un seul bloc.
Et en fonction du système de fichiers, le répertoire peut contenir (ou pas) différentes informations sur le fichier considéré (date de création, taille…).
Mais en aucun cas il ne contiendra les données du fichier.

Amicalement.

Jean-Marie

[tony]

Comme je te l’ai dit en #4, un répertoire ne contient pas les fichiers. Tout ce qu’il contient, c’est le nom du fichier et un numéro d’inode qui est un pointeur vers un espace de stockage du support d’information où se trouve le début des donnees du fichier. Ensuite, les inodes sont chaînés pour trouver la suite des données si celles-ci ne tiennent pas sur un seul bloc.
Et en fonction du système de fichiers, le répertoire peut contenir (ou pas) différentes informations sur le fichier considéré (date de création, taille…).
Mais en aucun cas il ne contiendra les données du fichier.

Amicalement.

Jean-Marie

effectivement, mais je butais sur cette histoire d'espace occupé qui semblait dire le contraire. Il faut du temps pour que ça décante et je dois retrouver un résultat par moi-même si je veux l'assimiler.

PS: on ne lit jamais assez attentivement le manuel:

du - Évaluer l'espace disque occupé par des fichiers
.........

DESCRIPTION
Totaliser l'espace utilisé sur le périphérique par l'ensemble de FICHIERS,
de façon récursive pour les répertoires

[diesel]

Pour avoir la taille du fichier (ou de plusieurs), deux solutions :
- l’information est écrite dans le répertoire,
- le répertoire contenant un pointeur vers le début des données, un outil peut aller lire celles-ci pour calculer la taille le moment voulu.

Amicalement.

Jean-Marie

[piratebab]

Et pour complexifier le tout, un nom de fichier ne contient pas la fichier. C'estp our ça qu'il est de taille fixe (dont je ne me rappelle plus la valeur, 4k il me semble). Il contient seulement l'adresse physique du premier block de données sur le disque.
Lorsqu'on "efface" un fichier, on se contente de couper ce lien , et le premier block du fichier est maintenant disponible si besoin de place pour un autre bloc de données.
C'est grace à cela qu'on peux lire des fichiers, même si ils ont été "effacè".
Pour vraiment supprimer les données, il faut forcer l'écriture d'une valeur aléatoire dans les blocks qui contenanaient les données.