Vous n'êtes pas identifié(e).
~$
~$
~$
~$
$
~$
~$
..........jusqu'ici pas de soucis.
~$
............MAIS:
~$
~$
~$
~$
~$
~$
~/Bureau$
~/Bureau$
~/Bureau$
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.
Dernière modification par MdgRUN (26-11-2017 16:03:29)
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
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).
Il vaut mieux montrer que raconter.
Hors ligne
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 :
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
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
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.
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.
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.
Il vaut mieux montrer que raconter.
Hors ligne
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.
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
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" ?
me permet de trouver la taille des blocs.....que je peux multiplier par 24 ?
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?
~$
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:
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 :
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 )
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.
Edit à toto :
Mis les balises du forum quote et code en ordre...
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
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.
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.
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.
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.
Il vaut mieux montrer que raconter.
Hors ligne
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:
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:
et
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.
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
à 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 ?
J'ai parcouru :
https:www.//debian.org/doc/manuals/debi … ring_data/
Cet URL est invalide. // ou www. n'est pas bien placé.
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.
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.
Il vaut mieux montrer que raconter.
Hors ligne
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.
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 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; ...........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.
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
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
j'ai interrogé ma Jessie avec:
qui est très fière, se sent très robuste de la tête aux pieds en EXT4.......quant à supporter GRUB........
Model: ATA HGST HTS545050A7 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 30,0GB 30,0GB primary ext4 boot
2 30,0GB 500GB 470GB extended
5 30,0GB 33,0GB 2999MB logical ext4
6 33,0GB 41,3GB 8347MB logical linux-swap(v1)
7 41,3GB 41,7GB 398MB logical ext4
8 41,7GB 500GB 458GB logical ext4
Elle attend avec curiosité comment l'ancien système va gérer un débit de 64 bits
Je présume qu'il y aura des applications incompatibles et je ne me vois pas compléter des liens ( quels que soient les octets en cause:rolleyes )
Je ne suis vraiment pas sûr qu'un codage en 64 bits ( 8 octets partout ?) correspondent à une meilleure utilisation de(s) mémoire(s)....
Je m'attends donc à revenir faire appel à l'intelligence collective du forum ,à la tienne en particulier.
en assumant ma cacaophilie.
Voir le tuto : C'est résolu ! Bravo mais il faut l'indiquer dans l'titre.
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
en assumant ma cacaophilie.
Raté, c'est aux autres membres de gagner le point choco df avec ce lien pour l'oubli d'indiquer le résolu du post.
Chenapan, va !
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Raté, c'est aux autres membres de gagner le point choco df
L'abbé Pierre aurait-il dit:<<Cacaophilie bien partagée commence par soi-même....>> ?
Quant à la résolution du sujet, c'est surtout pour les utilisateurs de lecteurs SSD que la réponse semble dans la commande:
Quant à mes oublis.......je table sur les vertus du chocolat: Au lait, noir, aux amandes, en poudre, chaud ou froid.....:lol:
Alors, ce "post"? C'est résolu,.... quand même?
**Donnez une poignée de sable à un poète,il en fera des étoiles **
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne