fabriquer un alias d'alias

24 réponses

pere.noel

04/09/2006 à 09:12

je cherche un moyen pour fabriquer un alias d'alias (but : tester une
extension C pour Ruby).

le problème :

si je crée un "target_alias" d'un fichier "target" puis un
"alias_of_alias" de l'alias "target_alias" j'obtiens un alias qui pointe
directement sur "target", ce qui n'est pas le but recherché...

j'ai essayé de "ruser" ))

je crée un fichier texte vode "target_alias" par touch ;
je crée un alias de celui-ci "alias_of_alias" ;
je supprime "target_alias" par rm -f ;
je crée un fichier quelconque "target" ;
enfin je crée un alias "target_alias de "target".

pas de pot "alias_of_alias" pointe quand même directement sur "target"
et non, ce que je recherche, sur "target_alais".

qq'un sur la liste as-patpro a répondu "impossible" de même sur la liste
alt.comp.lang.applescript.

ça me gène de produire un code dont une fonctionalité n'est pas testée :

OSErr FSResolveAliasFile (
FSRef * theRef,
Boolean resolveAliasChains, // <== c'est ce que je souhaite tester...
Boolean * targetIsFolder,
Boolean * wasAliased
);
--
une bévue

10 réponses

1 2 3

Patrick Stadelmann

04/09/2006 à 16:02

In article <1hl5c5n.1kg2al33kx8nN%,
(Une bévue) wrote:

par contre le dump hexa vers une plist d'un AliasRecord m'intéresse,
c'est ce qui est appellé AliasHandle dans la docum ???

Un AliasHandle c'est un pointeur vers un pointeur sur un AliasRecord. Le
contenu de l'AliasRecord peut être stocké dans un fichier, en général
dans une ressource de type 'alis' mais on peut aussi récupérer le
contenu, le stocker comme on veut, et remettre le tout dans un Handle
(crée avec NewHandle) que l'on peut ensuite passer à toute fonction
attendant un AliasHandle. Cela dit il y a peut-être un mécanisme pour
gérer cela dans Mac OS X.

Patrick
--
Patrick Stadelmann

Saïd

04/09/2006 à 16:04

Une bévue :

Patrick Stadelmann wrote:

on ne peut avoir dans un fichier "pur unix" un ensemble d'AliasHandle
comme produit par des AliasRecords ??

Qu'entends-tu par : fichier "pur Unix" ? On peut stocker les AliasRecord
où on veut (e.g. sous forme de "dump" hexadécimal dans un fichier
.plist) mais le Finder ne peut les exploiter directement que via des
fichier de type "alias".

ok pas de possibilté "pure unix" pour un alias record.

par contre le dump hexa vers une plist d'un AliasRecord m'intéresse,
c'est ce qui est appellé AliasHandle dans la docum ???

je cherche à créer une extension C pour Ruby qui crée un/des
AliasRecord(s) et stocke le contenu soit dans une plist soit dans un
fichier yaml (+ utilisé sur ruby que plist).

Si tu veux de la portabilite vers d'autres Unix, tu oublies les alias.
C'est clair? ;-)

Ou alors tu utilises des liens symboliques, sachant que ces liens n'ont
aucune garantie pour suivre un fichier qui est deplace. Il est meme garantie
qu'une fois que le fichier original est deplace, le lien symbolique est
cassé.

Ou alors les liens hards, qui suivent les deplacements (en fait ca revient
a creer un fichier equivalent au fichier d'origine, mais sans dupliquer les
donnees) mais ne disparaissent pas quand le fichier d'"origine" est efface.

--
Saïd.
"Bless this, O Lord, that with it thou mayst blow thine enemies to tiny
bits, in thy mercy."
In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)

Eric Levenez

04/09/2006 à 17:51

Le 4/09/06 16:04, dans , « Saïd »
a écrit :

Si tu veux de la portabilite vers d'autres Unix, tu oublies les alias.
C'est clair? ;-)

Oui, chef ! :-)

Ou alors tu utilises des liens symboliques, sachant que ces liens n'ont
aucune garantie pour suivre un fichier qui est deplace.

C'est souvent leur principal intérêt. Il suffit de regarder le coeur unix de
Mac OS X pour voir que ce sont les liens symboliques qui sont utilisés pour
gérer les fichiers de configurations.

Les alias sont souvent très pénibles par le fait que justement ils
retrouvent un fichier que l'on a placé un en répertoire "old" et dont a
remplacé le fichier original qui est inconnu de l'alias.

Il est meme garantie
qu'une fois que le fichier original est deplace, le lien symbolique est
cassé.

Oui, et c'est bien :-)

Ou alors les liens hards, qui suivent les deplacements (en fait ca revient
a creer un fichier equivalent au fichier d'origine, mais sans dupliquer les
donnees) mais ne disparaissent pas quand le fichier d'"origine" est efface.

Là il faut bien comprendre qu'avec un lien dur, il n'y a pas d'original ou
de copie, il y a juste un fichier qui a 2 (ou plusieurs) noms.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

pere.noel

04/09/2006 à 19:53

Saïd wrote:

Si tu veux de la portabilite vers d'autres Unix, tu oublies les alias.
C'est clair? ;-)

ce que je souhaite :
laisser la possibilité à l'utilisateur de déplacer|renommer ces fichiers
comme il le souhaite SANS que mon prog les perdent de vue.

pour l'instant, effectivement, je crée des laias d'un un rép cache (pas
recommandé par Apple).

aujourd'hui je souhaite passer à des alias record dont le contenu (alis)
se retrouvera dans un fichier prefs (plist ou yaml).

mon prog n'est pas portable pour d'autres raisons.
--
une bévue

pere.noel

04/09/2006 à 19:53

Eric Levenez wrote:

Ou alors les liens hards, qui suivent les deplacements (en fait ca revient
a creer un fichier equivalent au fichier d'origine, mais sans dupliquer les
donnees) mais ne disparaissent pas quand le fichier d'"origine" est efface.

Là il faut bien comprendre qu'avec un lien dur, il n'y a pas d'original ou
de copie, il y a juste un fichier qui a 2 (ou plusieurs) noms.

mais sont-ils aussi souples que les alias record ?
autre question quand est-ce qu'un hardlink casse, est orphelin ?
peut-on le détecter facilement ?
--
une bévue

Saïd

04/09/2006 à 21:04

Une bévue :

autre question quand est-ce qu'un hardlink casse, est orphelin ?

Jamais. Sauf si on l'efface lui-meme.

peut-on le détecter facilement ?

Non, parce qu'on a aucune idee de qui est l'"original" (noter les
guillemets autour de original).

Si ton programme maintien une base de donnees de fichiers d'un certain type
(pdf par exemple). Tu peux garder dans un base la position d'origine ainsi
que le md5sum du fichier. Si la position originale ne contient plus le
fichier tu peux faire un

find /Users/utilisateur -type f -name *pdf -exec md5sum {} ; |grep
md5sumdorigine (le tout sur une seule ligne)

pour retrouver le fichier original.

--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger

Eric Levenez

04/09/2006 à 21:05

Le 4/09/06 19:53, dans
<1hl5o3e.1muqao312t8aojN%, « Une bévue »
a écrit :

Eric Levenez wrote:

Là il faut bien comprendre qu'avec un lien dur, il n'y a pas d'original ou
de copie, il y a juste un fichier qui a 2 (ou plusieurs) noms.

mais sont-ils aussi souples que les alias record ?

Tout dépend de ce que l'_on_ veut faire. D'après ce que _tu_ veux faire
avec, non.

autre question quand est-ce qu'un hardlink casse, est orphelin ?
peut-on le détecter facilement ?

Cette question n'a pas de sens, du moins dans le sens où tu le penses.

Soit un fichier appelé "toto" et faisant 100 octets. Si l'on créé un lien
dur appelé "tata", alors on obtient un seul fichier sur disque mais avec 2
noms "toto et "tata". Il n'y a aucun maître ou esclave ou original ou copie.
C'est juste un fichier avec 2 noms. Si tu effaces un nom (par exemple sous
shell par "rm toto"), alors le fichier n'a pas bougé, et il ne porte plus
qu'un seul nom "tata". Si maintenant tu effaces ce "tata", le fichier n'a
plus de nom et le fichier s'en aperçoit et libère les blocs sur disque.

Pour être complet il peut arriver qu'un fichier avec 2 noms "toto" et "tata"
ait un nombre de liens à 3. Ceci est une erreur dans le système de fichiers
lié à un panic ou à un bug du noyau. La correction se fait par l'utilitaire
de réparation des disques : fsck.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Patrick Stadelmann

04/09/2006 à 22:43

In article <C122183B.7A3C7%,
Eric Levenez wrote:

Les alias sont souvent très pénibles par le fait que justement ils
retrouvent un fichier que l'on a placé un en répertoire "old" et dont a
remplacé le fichier original qui est inconnu de l'alias.

C'est toi qui a un problème avec eux car tu voudrais qu'ils se
comportent comme des symlinks :-) Or si Apple a pris la peine de créer
les alias au lieu de reprendre simplement le concept de symlink pour le
Système 7 c'est bien parce que leur but n'est pas simplement de
permettre un accès rapide à un point donné de la hiérarchie, mais bien
de suivre un fichier / dossier malgré les déplacement / changements de
noms.

Patrick
--
Patrick Stadelmann

Eric Levenez

04/09/2006 à 22:48

Le 4/09/06 22:43, dans
, « Patrick
Stadelmann » a écrit :

In article <C122183B.7A3C7%,
Eric Levenez wrote:

Les alias sont souvent très pénibles par le fait que justement ils
retrouvent un fichier que l'on a placé un en répertoire "old" et dont a
remplacé le fichier original qui est inconnu de l'alias.

C'est toi qui a un problème avec eux car tu voudrais qu'ils se
comportent comme des symlinks :-)

Non. Je dis juste que pour faire de l'administration, les alias sont une
plaie. Pour un utilisateur lambda qui ne sait pas où se trouve ce qu'il
range, cela peut être utile. Éventuellement. Probablement. Enfin peut-être.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

pere.noel

05/09/2006 à 07:10

Eric Levenez wrote:

Non. Je dis juste que pour faire de l'administration, les alias sont une
plaie. Pour un utilisateur lambda qui ne sait pas où se trouve ce qu'il
range, cela peut être utile. Éventuellement. Probablement. Enfin peut-être.

perso, ce que je vois comme utilisation "classique", un gars sur son
file system à une arborescence d'une profondeur p à l'instant t.

comme il a de plus en plus de fichiers, pour s'y retrouver il passe à la
prof p+1 et son alias, dans un menu de Finder Pop par ex est tjs
valable.

l'alias n'est pas, en partie, responsable de la convivialité du mac ?
--
une bévue

1 2 3

fabriquer un alias d'alias

10 réponses

Veuillez sélectionner un problème