Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Mac OS Autres OS Mac OS X Pour passer le temps: aliases qui engraissent

Pour passer le temps: aliases qui engraissent

101 réponses
Avatar
J.P
En septembre 2009, déjà sous SL, mes aliases pesaient 4Ko.
Ceux que je vois créés en octobre 2010 et depuis (toujours sous SL)
pèsent 1Mo.
1- pourquoi ?
2- un truc pour faire passer ceux de 1Mo à 4Ko ?
vu qu'à l'usage, je n'y vois aucune diférence. :-)

--
Jean-Pierre
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
7 8 9 10 11
Avatar
J.P
In article <1n4jl7z.3rslhx1fg58hoN%,
(Benoit) wrote:
J.P wrote:
S?icns?Sis32>??1?1????1?)
^^^^^^^^^^^^ Début de l'icone taille 32 je parie
...........
et des kilomètres à suivre

Das lesquels tu trouveras S?icns?Sis16> S?icns?Sis08> S?icns?Sis04> et
d'autres, je parie. Si tu fais une recherche sur « S?icns?S » tu trouves
quoi ? et plus simplement sur « ?icn » tu trouves quoi ?

Oui, oui, il y a ...
En cherchant "icn":
1 icns, 1 icn, 1 icN
c'est tout.
--
Jean-Pierre
Avatar
pdorange
J.P wrote:
Par ailleurs ce qui différencie un aliais d'un lien symbolique
(Unix/Mac) c'est que l'alias reste valable même si la source est renommé
ou déplacés (sur le même volume).

Sous 10.6.8
Je viens de faire l'essai de renommer puis déplacer (sur le même volume
système) un dossier pointé par un lien symbolique issu du "merveilleux"
script de JB.
La seule chose qui change est que le lien symbolique perd son icône qui
devient celle d'une page blanche et garde la petite flèche en bas à
gauche.
Dans les deux cas (déplacement, nom) le "lien symbolique JB" retrouve
l'original et l'ouvre.
Peut-être faut-il un logout pour que le lien soit cassé ?

Désolé de pas suivre, mais je sais pas ce qu'est un "lien symbolique JB"
Un lien symbolique se crée "normalement" avec la commande (shell) ln -s
; c'est peut être ce que fait le "script de JB" ?
Il existe de plus une différence entre "ln" (seul) et "ln -s". Le
premier ceée des "hardlink" et le second des "liens symboliques". J'ai
jamais trop compris la différence exacte mais les premiers ne concerne
que des fichiers et ne suive pas du tout la source. Les seconds suivent
parfois la source...
--
Pierre-Alain Dorange Moof <http://clarus.chez-alice.fr/>
Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Avatar
mv
Pierre-Alain Dorange a attiré mon
attention en écrivant :
Désolé de pas suivre, mais je sais pas ce qu'est un "lien symbolique JB"
Un lien symbolique se crée "normalement" avec la commande (shell) ln -s
; c'est peut être ce que fait le "script de JB" ?

Le «bidule» de JB est un script qui permet, par simple glisser/déposer
de créer où l'on souhaite un lien symbolique d'un dossier ou d'un
fichier. Pas besoin du Terminal donc. ;-)
Cordialement.
--
Michel Vauquois
<http://michelvauquois.free-h.fr>
85 nuances d'automne :
<http://matiere-a-voir-2.michelvauquois.free-h.fr>
Avatar
pehache
Le 18/04/2017 à 16:05, Pierre-Alain Dorange a écrit :
J.P wrote:
Par ailleurs ce qui différencie un aliais d'un lien symbolique
(Unix/Mac) c'est que l'alias reste valable même si la source est
renommé
ou déplacés (sur le même volume).

Sous 10.6.8
Je viens de faire l'essai de renommer puis déplacer (sur le même volume
système) un dossier pointé par un lien symbolique issu du "merveilleux"
script de JB.
La seule chose qui change est que le lien symbolique perd son icône qui
devient celle d'une page blanche et garde la petite flèche en bas à
gauche.
Dans les deux cas (déplacement, nom) le "lien symbolique JB" retrouve
l'original et l'ouvre.
Peut-être faut-il un logout pour que le lien soit cassé ?

Désolé de pas suivre, mais je sais pas ce qu'est un "lien symbolique JB"
Un lien symbolique se crée "normalement" avec la commande (shell) ln -s
; c'est peut être ce que fait le "script de JB" ?
Il existe de plus une différence entre "ln" (seul) et "ln -s". Le
premier ceée des "hardlink" et le second des "liens symboliques". J'ai
jamais trop compris la différence exacte mais les premiers ne concerne
que des fichiers et ne suive pas du tout la source. Les seconds suivent
parfois la source...

Pour comprendre la différence, il faut savoir que chaque fichier
physiquement présent sur le disque est décrit dans une table du système
de fichiers par un numéro d'index unique (inode). Par là-dessus, une
autre table du système de fichiers associe chaque nom de fichier à un
inode. On a donc :
nom de fichier --> inode --> contenu
Un lien symbolique est un fichier (presque) comme un autre dont le contenu
est le nom du fichier vers lequel il pointe.
fichier pointé : nom1 --> inode1 --> contenu1=...
lien symbolique : nom2 --> inode2 --> contenu2="nom1"
Un lien symbolique est géré au niveau du système de fichiers (un flag
est présent qui dit que le contenu est un lien avec un autre fichier),
mais aussi de l'OS. Quand une appli veut lire le fichier "nom2", l'OS voit
qu'il s'agit d'un lien symbolique, récupère "nom1" et renvoie à l'appli
contenu1 de façon transparente. Mais une appli peut aussi interroger l'OS
sur la nature de "nom2", et demander explicitement à lire contenu2. Si le
fichier pointé est supprimé ou déplacé, clairement le lien est cassé.
Un lien en dur au contraire n'a pas d'existence physique sur le disque,
c'est juste une entrée supplémentaire dans la table des noms vers un
inode déjà existant :
fichier pointé : nom1 --> inode1 |--> contenu1=...
lien en dur : nom2 --> inode1 |
Une fois créé, le lien en dur est indiscernable du fichier original et se
comporte exactement comme lui du point de vue de l'OS, qui n'a pas
"conscience" qu'il s'agit d'un lien. Effacer le fichier pointé n'empêche
pas d'accéder à contenu1 par l'intermédiaire du lien, car un inode n'est
effacé que lorsque plus aucun nom de fichier ne pointe vers lui. Pareil
s'il est déplacé : un déplacement de fichier n'est en fait qu'un
changement de nom (nom1 devient nom3) qui n'influe pas sur l'inode.
Avatar
pehache
Le 18/04/2017 à 17:19, pehache a écrit :
Le 18/04/2017 à 16:05, Pierre-Alain Dorange a écrit :
J.P wrote:
Par ailleurs ce qui différencie un aliais d'un lien symbolique
(Unix/Mac) c'est que l'alias reste valable même si la source est
renommé
ou déplacés (sur le même volume).

Sous 10.6.8
Je viens de faire l'essai de renommer puis déplacer (sur le même
volume
système) un dossier pointé par un lien symbolique issu du
"merveilleux"
script de JB.
La seule chose qui change est que le lien symbolique perd son icône qui
devient celle d'une page blanche et garde la petite flèche en bas à
gauche.
Dans les deux cas (déplacement, nom) le "lien symbolique JB" retrouve
l'original et l'ouvre.
Peut-être faut-il un logout pour que le lien soit cassé ?

Désolé de pas suivre, mais je sais pas ce qu'est un "lien symbolique JB"
Un lien symbolique se crée "normalement" avec la commande (shell) ln -s
; c'est peut être ce que fait le "script de JB" ?
Il existe de plus une différence entre "ln" (seul) et "ln -s". Le
premier ceée des "hardlink" et le second des "liens symboliques". J'ai
jamais trop compris la différence exacte mais les premiers ne concerne
que des fichiers et ne suive pas du tout la source. Les seconds suivent
parfois la source...

Pour comprendre la différence, il faut savoir que chaque fichier
physiquement présent sur le disque est décrit dans une table du système de
fichiers par un numéro d'index unique (inode). Par là-dessus, une autre
table du système de fichiers associe chaque nom de fichier à un inode. On a
donc :
nom de fichier --> inode --> contenu
Un lien symbolique est un fichier (presque) comme un autre dont le contenu
est le nom du fichier vers lequel il pointe.
fichier pointé : nom1 --> inode1 --> contenu1=...
lien symbolique : nom2 --> inode2 --> contenu2="nom1"
Un lien symbolique est géré au niveau du système de fichiers (un flag est
présent qui dit que le contenu est un lien avec un autre fichier), mais aussi
de l'OS. Quand une appli veut lire le fichier "nom2", l'OS voit qu'il s'agit
d'un lien symbolique, récupère "nom1" et renvoie à l'appli contenu1 de
façon transparente. Mais une appli peut aussi interroger l'OS sur la nature
de "nom2", et demander explicitement à lire contenu2. Si le fichier pointé
est supprimé ou déplacé, clairement le lien est cassé.
Un lien en dur au contraire n'a pas d'existence physique sur le disque,
c'est juste une entrée supplémentaire dans la table des noms vers un inode
déjà existant :
fichier pointé : nom1 --> inode1 |--> contenu1=...
lien en dur : nom2 --> inode1 |
Une fois créé, le lien en dur est indiscernable du fichier original et se
comporte exactement comme lui du point de vue de l'OS, qui n'a pas
"conscience" qu'il s'agit d'un lien. Effacer le fichier pointé n'empêche pas
d'accéder à contenu1 par l'intermédiaire du lien, car un inode n'est
effacé que lorsque plus aucun nom de fichier ne pointe vers lui. Pareil s'il
est déplacé : un déplacement de fichier n'est en fait qu'un changement de
nom (nom1 devient nom3) qui n'influe pas sur l'inode.

En conséquence, si les "liens de JB" ne sont pas cassés par un changement
de nom ou déplacement de la source, ce sont probablement plutôt des liens
"en dur".
Avatar
mv
pehache a attiré mon attention en écrivant :
En conséquence, si les "liens de JB" ne sont pas cassés par un changement
de nom ou déplacement de la source, ce sont probablement plutôt des liens
"en dur".

Chez moi, le "lien de JB" est cassé dès que je déplace un dossier (sans
changer de disque) mais pas si je change le nom du dossier original.
Cordialement.
--
Michel Vauquois
<http://michelvauquois.free-h.fr>
85 nuances d'automne :
<http://matiere-a-voir-2.michelvauquois.free-h.fr>
Avatar
g4fleurot
pehache aimerait obtenir une réponse à sa question :
le lien vers quoi ? vers le dossier ? vers un fichier contenu dans le
dossier

C'est un lien symbolique :
Extrait du script :
do shell script ("ln -s " & quoted form of posix_path & " " & quoted
form of (posixSLPath))
--
Gérard FLEUROT plus un
Avatar
mv
pehache a attiré mon attention en écrivant :
Chez moi, le "lien de JB" est cassé dès que je déplace un dossier (sans
changer de disque) mais pas si je change le nom du dossier original.

le lien vers quoi ? vers le dossier ? vers un fichier contenu dans le
dossier ?

C'est écrit ici : "si je change le nom du dossier original". Je parlais
donc d'un lien vers un dossier. Mais c'est kif kif si le lien est issu
d'un fichier (l'original n'est pas trouvé si je le bouge et il est
retrouvé si je me contente de modifier son nom).
Cordialement.
--
Michel Vauquois
<http://michelvauquois.free-h.fr>
85 nuances d'automne :
<http://matiere-a-voir-2.michelvauquois.free-h.fr>
Avatar
josephb
Bonsoir,
pehache émit :
En conséquence, si les "liens de JB" ne sont pas cassés par un changement
de nom ou déplacement de la source, ce sont probablement plutôt des liens
"en dur".

Puisque j'ai commis ce bidule, je donne juste deux précisions qui vont
alimenter le flou de cette discussion
la première, oui, avec la commande "ln -s " dans le script, on est
clairement dans du lien symbolique
la seconde est que selon la version de l'OS, le comportement du lien
symbolique créé par le droplet est légèrement différente :
Avec El Cap que MV avait lorsqu'il participait aux tests, le
déplacement de l'original cassait le lien. Il semble qu'il en soit
toujours ainsi avec Sierra.
Avec Lion, sur ma machine, déplacer (sur le même disque) ou
changer le nom de l'original se contente d'en faire perdre l'icône
personnalisée sur le symlink (dont le nom reste inchangé dans tous les
cas, de même que son poids de 4 Ko), mais ne casse pas le lien.
(Fastoche !)
Je ne me rappelle plus quel était le comportement avec SL, dans le même
cas, lorsque que JP P. faisait les tests.
Pour ne pas embrouiller l'utilisateur, j'avais omis de mentionner ces
particularités, selon la version d'OS X, dans le read-me, déclarant à
minima que déplacer l'original casserait le lien, mais ce n'est pas
toujours vrai, au vu de mon expérience.
En tout cas, si les nouvelles version de Sierra savent maintenant gérer
les Alias sans les rendre obèses, ce sera parfait et rendra mon bidule
inutile.
--
J. B.
Avatar
J.P
In article <1n4p1d0.lb9vls40tdexN%,
(M.V.) wrote:
...si le lien est issu
d'un fichier (l'original n'est pas trouvé si je le bouge et il est
retrouvé si je me contente de modifier son nom).

Ce qui précède: sous Sierra, je suppose.
Ici, sous SL 10.6.8,
la séquence est importante !
je crée une copie d'un dossier enfoui bien profond.
je crée un lien symbolique (LSym) de ce dossier sur le bureau
- <clic droit sur LSym/Show original>: il me le montre; évidemment :-)
- si je déplace ce dossier, LSym le retrouve, y compris après
plusieurs déplacements successifs.
- si, dans ce nouvel emplacement, je le renomme: LSym le retrouve.
- si je le mets à la poubelle, LSym le retrouve.
je fais un Secure empty trash
je recrée un dossier du même nom dans l'emplacement d'origine:
LSym le retrouve !!!
(si je me déconnecte (logout) et me reconnecte, le lien est cassé)
MAIS:
la séquence est importante !
je crée une copie d'un dossier enfoui bien profond.
je crée un lien symbolique (LSym) de ce dossier sur le bureau
JE NE FAIS PAS <Show original>
- si je renomme immédiatement ce dossier, LSym ne le retrouve pas.
- si je déplace immédiatement ce dossier, LSym ne le retrouve pas
- si je le remets à sa place, LSym le retrouve,
- si je le déplace de nouveau au même endroit, LSym le retrouve !
- si je le renomme , LSym le retouve
- si je le déplace n'importe où, y compris dans la poubelle sous ce
nouveau nom, LSym le retrouve.
Conclusion:
Sous SL, si un lien symbolique a pointé une fois correctement sur son
original, on peut déplacer/renommer cet original sans que le lien soit
cassé, tant qu'on ne s'est pas déconnecté.
Faut vraiment avoir du temps à perdre :-)
--
Jean-Pierre
7 8 9 10 11