Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 26-10-2017 16:04:00

MdgRUN
Membre
Lieu : La Réunion (974)
Distrib. : EMMABUNTUS-DE Jessie
Noyau : 3.6 --->4.8
(G)UI : Xfce
Inscription : 27-09-2016

Des OCTETS et des LIENS......

Bonjour à tous,

voici les manipulations que j'ai tenté pour amener un lien sur mon bureau à partir de mon répertoire perso:

~$

ln -s FICHIER FICHsymb


~$

ls


Bibliothèque calibre         FICHIER     messages   sort
Bureau                       FICHsymb    mkusb.log  Téléchargements




~$

ls -i FICHsymb


13636227 FICHsymb


~$

ls -i FICHIER


13636203 FICHIER



~$

ln -s FICHsymb FICHsymb2


$

ls -i FICHIER FICHsymb2


13636203 FICHIER  13636274 FICHsymb2



~$

ln -s FICHIER Bureau/FICHsymb



~$

ls -i FICHIER Bureau/FICHsymb


13636283 Bureau/FICHsymb  13636203 FICHIER

..........jusqu'ici pas de soucis.

~$

wc FICHIER


 3 21 96 FICHIER

............MAIS:

~$

wc Bureau/FICHsymb FICHsymb


wc: Bureau/FICHsymb: Aucun fichier ou dossier de ce type
 3 21 96 FICHsymb
 3 21 96 total



~$

ln FICHsymb Bureau/FICHdur



~$

wc Bureau/FICHdur


wc: Bureau/FICHdur: Aucun fichier ou dossier de ce type



~$

ln FICHsymb Bureau/FICHdur


ln: impossible de créer le lien direct 'Bureau/FICHdur': Le fichier existe............et apparaît en affichant 7 octets.



~$

wc FICHdur FICHIER FICHsymb


  3  21  96 FICHdur
  3  21  96 FICHIER
  3  21  96 FICHsymb
  9  63 288 total



~$

 ls -i FICHdur FICHIER FICHsymb


13636227 FICHdur  13636203 FICHIER  13636227 FICHsymb



~/Bureau$

ls -i F


Famille1.JPG        FICHdur             ForetDhauts/
Famille3-10x15.JPG  FICHsymb            
FANterieur/         FONTAINuisanceS/    



~/Bureau$

ls -i FICHdur FICHsymb


13636227 FICHdur  13636283 FICHsymb



~/Bureau$

wc FICHdur FICHsymb


wc: FICHdur: Aucun fichier ou dossier de ce type
wc: FICHsymb: Aucun fichier ou dossier de ce type
0 0 0 total



Quelle différence de nature entre la commande "ls" et "wc" pour que cette dernière ne fonctionne pas ici?
Pourriez-vous m'en suggérer une autre?

Peut-on identifier/localiser les octets mobilisés,affichés par les liens sur le bureau?
Comment,plus généralement ,"décortiquer" une inode? La "rationnaliser"?

L'idée serait de  créer des liens moins "lourds" que le fichier initial.


Edit à toto :

Mis les commandes user sous la balise Commande user du forum séparées de leurs retours respectifs.


La bonne question est celle qui n'a pas été encore posée.

En ligne

#2 26-10-2017 17:28:20

raleur
Membre
Inscription : 03-10-2014

Re : Des OCTETS et des LIENS......

La différence entre ls et wc est que ls se contente de lire le contenu du répertoire alors que wc lit le contenu du fichier. Un lien cassé ne perturbe donc pas ls.

Il y a une subtilité à connaître quand on crée un lien symbolique : l'emplacement source est copié littéralement dans le lien, et interprété comme un chemin relatif par rapport à la position courante du lien symbolique (et non par rapport au répertoire courant) s'il ne commence pas par /.

Dans ton cas, il aurait fallu mettre ../FICHIER comme source puisqu'elle est dans le répertoire parent du repertoire contenant le lien symbolique, ou bien le chemin absolu complet de la source. Pour utiliser la complétion du shell, il vaut mieux se placer dans le répertoire de destination où le lien va être créé.

MdgRUN a écrit :

Peut-on identifier/localiser les octets mobilisés,affichés par les liens sur le bureau?


Je ne comprends pas ce que tu appelles "octets mobilisés".
La taille d'un lien symbolique est simplement la taille du chemin cible (source).

Hors ligne

#3 30-10-2017 12:08:58

MdgRUN
Membre
Lieu : La Réunion (974)
Distrib. : EMMABUNTUS-DE Jessie
Noyau : 3.6 --->4.8
(G)UI : Xfce
Inscription : 27-09-2016

Re : Des OCTETS et des LIENS......

Bonjour raleur en te remerciant pour la subtilité que j'ai mis à profit, voici ce que j'obtiens.....avec je l'espère les bonnes balises wink et la
complétion sans modération big_smile

file Bureau/FICHsymbASTUCE2 Bureau/FICHdurASTUCE
Bureau/FICHsymbASTUCE2: symbolic link to ../FICHIER
Bureau/FICHdurASTUCE:   ASCII text


df -Pih  Bureau/FICHsymbASTUCE2 Bureau/FICHdurASTUCE
Sys. de fichiers      Inœuds IUtil. ILibre IUti% Monté sur
/home/daniel/.Private    15M   723K    14M    5% /home/daniel
/home/daniel/.Private    15M   723K    14M    5% /home/daniel


du  Bureau/FICHsymbASTUCE2 Bureau/FICHdurASTUCE
4 Bureau/FICHsymbASTUCE2
12  Bureau/FICHdurASTUCE


 ls -i FICHIER FICHsymb FICHsymb2
13636203 FICHIER  13636227 FICHsymb  13636274 FICHsymb2



 wc  FICHIER FICHsymb FICHsymb2
 12  43 216 FICHIER
 12  43 216 FICHsymb
 12  43 216 FICHsymb2
 36 129 648 total



ls -i Bureau/FICHsymbASTUCE2 Bureau/FICHdurASTUCE
13636203 Bureau/FICHdurASTUCE  13636318 Bureau/FICHsymbASTUCE2



qui me permettent de constater que le lien dur est bien sur la même inode que le fichier initial alors que les liens symboliques mentionnent à chaque fois
des inodes différentes........ainsi qu'une copie classique.

Si on veut économiser des inodes et donc de la place sur sa machine, il faut donc se servir de "liens durs".

Je présume qu'en affinant les tuyaux on peut se servir de :

 ls Bureau > MonBUREAU | cat MonBUREAU | wc
     87     106    1374
 



Mon fichier du départ en texte simple (O.K. je sais qu'il y a de l'ASCII étendu.... ) me semble bien loin des 256 valeurs possibles codables  (2^8) sur un octet.....et encore
plus loin de la contenance d'une "inode".

Me voici donc avec un FICHIER de 216 octets mais Je sais bien que je suis alors de mon côté utilisateur et ma  question ( avec toutes les naïvetés d'un non-informaticien) concerne plus le noyau du systême:

Comment lit-il (code -t -il ?) mon fichier? Je sais que ces satanés octets ont des  ruses de sioux pour se ranger du plus petit au plus gros:

https://fr.wikibooks.org/wiki/Repr%C3%A … des_octets        ou encore:

https://fr.wikipedia.org/wiki/Indicateu … des_octets    où les traces des premiers américains ne font que m'embrouiller.

Je me suis déjà amusé avec la commande "truncate" pour un résultat à l'aveuglette par rapport à l'utilisation de "sed/head/tail......sort/cut......." en pensant qu'il pouvait
être bon pour des raisons de sécurité de combler tous les vides d'un fichier, d'une inode.......par des 0 à partir de la commande "dd"......mais peut-on envisager un remplissage de 1 ?

Le dialecte binaire des indiens ne m'effraie pas vraiment mais je ne sais pas par quelle méthode commencer......et pour le scalp c'est déjà fait sad


La bonne question est celle qui n'a pas été encore posée.

En ligne

#4 30-10-2017 14:27:47

raleur
Membre
Inscription : 03-10-2014

Re : Des OCTETS et des LIENS......

MdgRUN a écrit :

Si on veut économiser des inodes et donc de la place sur sa machine, il faut donc se servir de "liens durs".


Certes un lien symbolique occupe un inode supplémentaire, mais pas forcément de bloc de données supplémentaire si la taille du chemin qu'il cible est suffisamment courte pour contenir dans l'inode lui-même (sur mon système c'est environ 60 octets).

D'autre part les liens durs et les liens symboliques ne fonctionnent pas de la même façon et n'ont donc pas le même usage.

Un lien dur ne peut être créé que sur le même système de fichiers et ne peut pas viser un répertoire.
Un lien dur est vraiment équivalent au fichier d'origine (qui n'est autre qu'un lien dur lui-même) puisque les deux pointent vers le même inode. Si le fichier d'origine est renommé ou déplacé, le lien dur continue à pointer vers le même contenu. Si le fichier d'origine est supprimé, son contenu reste accessible via le lien dur.

Un lien symbolique est un fichier distinct, qui cible non pas l'inode mais le chemin du fichier d'origine. Contrairement au lien dur il peut cibler un répertoire et un chemin situé sur un autre système de fichiers.
Si on renomme ou déplace le fichier d'origine, le lien symbolique est dit "cassé", il cible un chemin inexistant. Si on remplace le fichier d'origine (renommé ou remplacé) par un autre, le lien symbolique cible le nouveau fichier qui se trouve à cet emplacement dans l'arborescence.

MdgRUN a écrit :

Mon fichier du départ en texte simple (O.K. je sais qu'il y a de l'ASCII étendu.... ) me semble bien loin des 256 valeurs possibles codables  (2^8) sur un octet.....et encore plus loin de la contenance d'une "inode".


Je ne comprends pas ce que tu veux dire, ni le rapport entre la taille d'un fichier et le nombre de valeurs codables avec un octet.

MdgRUN a écrit :

le noyau du systême:
Comment lit-il (code -t -il ?) mon fichier? Je sais que ces satanés octets ont des  ruses de sioux pour se ranger du plus petit au plus gros:


Le noyau n'est pas concerné par le contenu des fichiers de données. Ce sont les programmes qui se débrouillent avec. Le noyau ne s'occupe que des binaires exécutables.

Hors ligne

#5 05-11-2017 16:08:51

MdgRUN
Membre
Lieu : La Réunion (974)
Distrib. : EMMABUNTUS-DE Jessie
Noyau : 3.6 --->4.8
(G)UI : Xfce
Inscription : 27-09-2016

Re : Des OCTETS et des LIENS......

raleur a écrit :

un lien symbolique occupe un inode supplémentaire, mais pas forcément de bloc de données supplémentaire



Bonjour Raleur et merci d'attirer mon attention sur le bloc de données.

stat FICHIER


  Fichier : 'FICHIER'
   Taille : 216         Blocs : 24         Blocs d'E/S : 4096   fichier
Périphérique : 2dh/45d  Inœud : 13636203    Liens : 2



je retrouve bien le nbre d'octets, le N° de "nœud d'indexation" mais pourquoi seulement 2 liens ?

Ne sont repérés que les liens symboliques (1 dans le répertoire + 1 sur le Bureau )?

Cela confirmerait

raleur a écrit :

Un lien dur est vraiment équivalent au fichier d'origine (qui n'est autre qu'un lien dur lui-même)



..... à moins d'affiner la commande "stat" ?

stat -f FICHIER


  Fichier : « FICHIER »
 Identif. : 418758d047ca9e51 Longueur du nom : 143     Type : ecryptfs
Taille de bloc : 4096       Taille de bloc fondamentale : 4096
 Blocs : total : 59544736   libre : 44401949   disponible : 41371473
Inœuds : total : 15138816   libre : 14397906



me permet de trouver la taille des blocs.....que je peux multiplier par 24 ?

raleur a écrit :

un lien symbolique occupe un inode supplémentaire, mais pas forcément de bloc de données supplémentaire si la taille du chemin qu'il cible est suffisamment courte pour contenir dans l'inode lui-même (sur mon système c'est environ 60 octets).



C'est le chemin que tu mesures en 60 octets ? comment ?
C'est la taille de l'inode que tu obtiens ? comment?

stat FICHsymb


  Fichier : 'FICHsymb' -> 'FICHIER'
   Taille : 7           Blocs : 8          Blocs d'E/S : 4096   lien symbolique
Périphérique : 2dh/45d  Inœud : 13636227    Liens : 2




~$

stat Bureau/FICHsymbASTUCE2 Bureau/FICHdurASTUCE


  Fichier : 'Bureau/FICHsymbASTUCE2' -> '../FICHIER'
   Taille : 10          Blocs : 8          Blocs d'E/S : 4096   lien symbolique
Périphérique : 2dh/45d  Inœud : 13636318    Liens : 1


 Fichier : 'Bureau/FICHdurASTUCE'
   Taille : 288         Blocs : 24         Blocs d'E/S : 4096   fichier
Périphérique : 2dh/45d  Inœud : 13636203    Liens : 2
Accès : (0664/-rw-rw-r--)

 




Je constate que dans le mếme répertoire le lien symbolique, pour un même nombre de blocs, a 3 octets de moins que
son équivalent sur le bureau......3 octets de chemin?

Enfin, alors que  les permissions sont totales pour les liens symboliques , ma distribution les restreint pour les liens en dur.......ce qui confirme:

raleur a écrit :

D'autre part les liens durs et les liens symboliques ne fonctionnent pas de la même façon et n'ont donc pas le même usage.



Je ne manquerai pas de venir te faire râler si je me branche "sécurité" : lol :

raleur a écrit :

Je ne comprends pas ce que tu veux dire, ni le rapport entre la taille d'un fichier et le nombre de valeurs codables avec un octet.



Je dois avouer qu'avant tes réponses, j'avais éludé l'aspect dynamique de stockage des infos sur un fichier et largement sous-estimé le travail de compatibilité
des informaticiens pour porter, envoyer, les données d'un systême à l'autre.

J'ai beaucoup de mal à ne pas me représenter un nombre binaire comme un signal Morse ,à appréhender les divers langages informatiques et je peste contre une éducation qui n'en favorise pas au moins autant l'approche que les langues (vivantes ou moribondes hmm )

Dans mon souci de rationnaliser le stockage dans mes zordis j'ai bien trouvé ceci:
https://stackoverflow.com/questions/466 … -directory

en sachant qu'il existe une commande mkfs capable de moduler la taille des blocs.


<<Ceux qui écrivent clairement ont des lecteurs ; ceux qui écrivent obscurément ont des commentateurs.>>disait Albert Camus....je suis ravi de connaître un raleur. smile

Edit à toto :

Mis les balises du forum quote et code en ordre...


La bonne question est celle qui n'a pas été encore posée.

En ligne

#6 06-11-2017 11:34:26

raleur
Membre
Inscription : 03-10-2014

Re : Des OCTETS et des LIENS......

MdgRUN a écrit :

pourquoi seulement 2 liens ?


"Seulement" ? La plupart des fichiers n'ont qu'un seul lien. Il s'agit bien sûr des seuls "liens physiques" (hard links). Les liens symboliques ne comptent pas.

MdgRUN a écrit :

me permet de trouver la taille des blocs.....que je peux multiplier par 24 ?


24 blocs de 4096 octets pour un fichier de 216 octets peut sembler beaucoup.Néanmoins certains systèmes de fichiers comme ext4 font une pré-réservation de blocs contigus pour permettre à un fichier de s'agrandir sans être trop fragmenté. Sur mon système en ext4 c'est seulement 8 blocs pour un fichier normal (je ne me souviens plus si c'est différent pour un lien symbolique). D'autre part stat -f indique qu'il s'agit d'un système de fichiers ecryptfs (utilisé pour ton /home comme dans Ubuntu ?), qui est une couche intermédiaire de chiffrement, cela a peut-être une influence sur la taille d'allocation.

MdgRUN a écrit :

C'est le chemin que tu mesures en 60 octets ? comment ?


Je compte le nombre de caractères dans le chemin contenu dans le lien symbolique. Les caractères non ASCII encodés en UTF-8 doivent occuper plusieurs octets, c'est à la louche.

MdgRUN a écrit :

Enfin, alors que  les permissions sont totales pour les liens symboliques


C'est toujours le cas, car les permissions des liens symboliques sont ignorées, seules celles de la cible sont prises en compte.
Les permissions des liens durs sont celles de l'inode cible.

Hors ligne

#7 12-11-2017 17:40:19

MdgRUN
Membre
Lieu : La Réunion (974)
Distrib. : EMMABUNTUS-DE Jessie
Noyau : 3.6 --->4.8
(G)UI : Xfce
Inscription : 27-09-2016

Re : Des OCTETS et des LIENS......

Bonjour raleur,

raleur a écrit :

La plupart des fichiers n'ont qu'un seul lien. Il s'agit bien sûr des seuls "liens physiques" (hard links). Les liens symboliques ne comptent pas.



à mon tour de raler......contre la commande "je donne le nombre de liens...." stat....... qui est donc limitée aux méta-données de l'inode ?

Entre liens durs et liens symboliques il me semble évident que l'on va trouver plus d'inodes occupées que de fichiers sur la machine, sans compter les inodes disponibles (je ne dirai plus "vides") et je note avec intérêt:

raleur a écrit :

Néanmoins certains systèmes de fichiers comme ext4 font une pré-réservation de blocs contigus pour permettre à un fichier de s'agrandir sans être trop fragmenté. Sur mon système en ext4 c'est seulement 8 blocs pour un fichier normal



On peut donc dire qu 'en "ext4" les fichiers seront plus "cohérents", plus "solides".....un facteur de sécurité ?

J'ai parcouru :

https:www.//debian.org/doc/manuals/debi … ring_data/

avant de sonder mon système:

 lsblk




NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0 232,9G  0 disk
├─sda1                         8:1    0   243M  0 part /boot
├─sda2                         8:2    0     1K  0 part
└─sda5                         8:5    0 232,7G  0 part
  ├─ubuntu--gnome--vg-root   252:0    0 230,9G  0 lvm  /
  └─ubuntu--gnome--vg-swap_1 252:1    0   1,8G  0 lvm  
sr0                           11:0    1  1024M  0 rom  
 



fdisk -l



 Disque /dev/sda : 232,9 GiB, 250059350016 octets, 488397168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000a9db4

Périphérique Amorçage  Start       Fin  Secteurs   Size Id Type
/dev/sda1    *          2048    499711    497664   243M 83 Linux
/dev/sda2             501758 488396799 487895042 232,7G  5 Étendue
/dev/sda5             501760 488396799 487895040 232,7G 8e LVM Linux




Disque /dev/mapper/ubuntu--gnome--vg-root : 230,9 GiB, 247921115136 octets, 484220928 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disque /dev/mapper/ubuntu--gnome--vg-swap_1 : 1,8 GiB, 1874853888 octets, 3661824 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
 



et

parted -l



Modèle: ATA ST9250315AS (scsi)
Disque /dev/sda : 250GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:

Numéro  Début   Fin    Taille  Type      Système de fichiers  Fanions
 1      1049kB  256MB  255MB   primary   ext2                 démarrage
 2      257MB   250GB  250GB   extended
 5      257MB   250GB  250GB   logical                        lvm (gestionnaire de volumes logiques)


Erreur: Impossible d'ouvrir /dev/mapper/ubuntu--gnome--vg-swap_1 - étiquette de
disque non reconnue.
Modèle: Mappeur de périphériques Linux (linear) (dm)                      
Disque /dev/mapper/ubuntu--gnome--vg-swap_1 : 1875MB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : unknown
Disk Flags:

Modèle: Mappeur de périphériques Linux (linear) (dm)
Disque /dev/mapper/ubuntu--gnome--vg-root : 248GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : loop
Disk Flags:

Numéro  Début  Fin    Taille  Système de fichiers  Fanions
 1      0,00B  248GB  248GB   ext4
 




et j'en déduis que cette  machine familiale à bien besoin de se moderniser (?)  en passant du format ext2 en ext4 par exemple.
Tout en ext4 ?

Peux-tu m'indiquer comment comprendre mes trois types de "Table de partitions" différents ( Msdos, inconnu et loop ) actuels?

Merci pour ta patience.


La bonne question est celle qui n'a pas été encore posée.

En ligne

#8 12-11-2017 22:36:36

raleur
Membre
Inscription : 03-10-2014

Re : Des OCTETS et des LIENS......

MdgRUN a écrit :

à mon tour de raler......contre la commande "je donne le nombre de liens...." stat....... qui est donc limitée aux méta-données de l'inode ?


Je ne comprends pas ce qui te contrarie. Que voudrais-tu que la commande stat affiche d'autre ?

MdgRUN a écrit :

J'ai parcouru :
https:www.//debian.org/doc/manuals/debi … ring_data/


Cet URL est invalide. // ou www. n'est pas bien placé.

MdgRUN a écrit :

j'en déduis que cette  machine familiale à bien besoin de se moderniser (?)  en passant du format ext2 en ext4 par exemple.
Tout en ext4 ?


C'est seulement /boot qui est en ext2, plus ancien, plus simple, donc supposément plus robuste et mieux supporté par GRUB. / et tout le reste est en ext4 dans un volume logique LVM.

MdgRUN a écrit :

Peux-tu m'indiquer comment comprendre mes trois types de "Table de partitions" différents ( Msdos, inconnu et loop ) actuels?


"msdos" est le type de table de partition du disque.
parted cherche une table de partition dans tous les volumes partitionnables. "loop" est sa façon de dire qu'il n'y a pas de table de partition. J'avoue que je comprends pas pourquoi il réagit différemment avec les deux volumes logiques.

Hors ligne

#9 14-11-2017 13:36:22

MdgRUN
Membre
Lieu : La Réunion (974)
Distrib. : EMMABUNTUS-DE Jessie
Noyau : 3.6 --->4.8
(G)UI : Xfce
Inscription : 27-09-2016

Re : Des OCTETS et des LIENS......

raleur a écrit :

Que voudrais-tu que la commande stat affiche d'autre ?



J'aurais aimé qu'elle me donne TOUS les liens ( "durs" ET "symboliques" )du fichier mais je veux bien comprendre que cette commande va prendre ses renseignements dans l'inode du fichier lui-même et n'a pas les références des inodes des chemins vers.....

Je présume qu'il y a là ,si ce n'est une limite de conception de la commande, une raison de sécurité pour les programmeurs .......une approche d'informaticien qui m'échappe malgré des liens comme:

http://www.linuxcertif.com/man/search/?keywords=stat/

Désolé pour : https://www.debian.org/doc/manuals/debi … 0.fr.html/
tu avais raison pour la place du "www" et je voulais pointer en particulier le 10.1.8. Choix de système de fichiers pour les données partagées.

raleur a écrit :

C'est seulement /boot qui est en ext2, plus ancien, plus simple, donc supposément plus robuste et mieux supporté par GRUB. / et tout le reste est en ext4

donc une distribution peut fort bien empiler des structures différentes, pour lesquelles les commandes doivent être aussi actualisées.
 
.......tout un poème big_smile si j'en juge par: http://www.linuxcertif.com/man/search/?keywords=parted

Pour la machine en question, je vais surtout refaire une installation en 64bits et essayer par les liens ad-hoc de préserver les habitudes, les environnements de ses utilisateurs à qui j'affirme qu'en informatique un mot c'est 16 bits, 32bits forment un "mot double" et qu'en "pensant" en 64 bits il y aura un gain de vitesse.
De là à y perdre quelques données; hmm  ...........de nouveaux fils à dérouler.

Pour revenir à la gestion des octets, permets-moi d'indiquer ce lien:

https://openclassrooms.com/forum/sujet/ … de-huffman

avant de porter ce sujet en "résolu" et t'attribuer des "points chocolats" en remerciements.


La bonne question est celle qui n'a pas été encore posée.

En ligne

Pied de page des forums