Journal : Liens symboliques persistants ??? Idée de workflow pour les e-mails.
Posté par Mildred (Jabber id, page perso, ) le 24 mars 2008
Bonsoir,
J'aimerais savoir si vous conaissez des projets visant a avoir des liens symboliques qui résistent au déplacement de leur cible ... A mon avis, c'est un point important qu'il est intéressant de développer.
Je sais que MacOS les implémentent ... Sans doute que Windows va bientôt s'y mettre (si ce n'est pas déjà fait).
L'interêt ? par exemple: pouvoir garder une trace des fichiers même si ils sont déplacés par l'utilisateur.
Mon but serait de créer un client mail qui fonctionnerait de la manière suivante:
- a l'arrivée de nouveaux messages, ils sont placés dans une mailbox définie (par exemple dans ~/Inbox/mails.mbox) ... d'éventuels filtres pourraient les mettre à un autre endroit.
- si un mail reçu contient une référence a un mail déjà reçu ou envoyé, le mail est placé dans la même mailbox que le mail qu'il cite. En cas de doutes, il est laissé dans inbox.
- l'utilisateur peut ouvrir une mailbox et voir son contenu. Déplacer un mail qu'il contient dans le système de fichiers (cela crée un fichier mbox avec un seul mail ... portant le nom du mail). L'utilisateur peut déplacer ses messages d'une mbox a l'autre
- la logiciel permettant de visualiser le contenu d'une mailbox aurait une barre latérale a gauche se souvenant des dernières mailboxes ouvertes par l'utilisateur. Il y aurait aussi des bookmarks de mailbox
Cette application nécessite de se souvenir des emplacements des mailboxes pour: savoir dans quel mailbox placer une réponse, afficher les dernières mailboxes ouvertes, garder des bookmarks de mailbox.
Pour le moment je n'ai pas encore écrit une seule ligne de cette application (je n'ai pas encore trouvé un couple langage/toolkit convenable).
J'aimerais savoir si vous conaissez des projets visant a avoir des liens symboliques qui résistent au déplacement de leur cible ... A mon avis, c'est un point important qu'il est intéressant de développer.
Je sais que MacOS les implémentent ... Sans doute que Windows va bientôt s'y mettre (si ce n'est pas déjà fait).
L'interêt ? par exemple: pouvoir garder une trace des fichiers même si ils sont déplacés par l'utilisateur.
Mon but serait de créer un client mail qui fonctionnerait de la manière suivante:
- a l'arrivée de nouveaux messages, ils sont placés dans une mailbox définie (par exemple dans ~/Inbox/mails.mbox) ... d'éventuels filtres pourraient les mettre à un autre endroit.
- si un mail reçu contient une référence a un mail déjà reçu ou envoyé, le mail est placé dans la même mailbox que le mail qu'il cite. En cas de doutes, il est laissé dans inbox.
- l'utilisateur peut ouvrir une mailbox et voir son contenu. Déplacer un mail qu'il contient dans le système de fichiers (cela crée un fichier mbox avec un seul mail ... portant le nom du mail). L'utilisateur peut déplacer ses messages d'une mbox a l'autre
- la logiciel permettant de visualiser le contenu d'une mailbox aurait une barre latérale a gauche se souvenant des dernières mailboxes ouvertes par l'utilisateur. Il y aurait aussi des bookmarks de mailbox
Cette application nécessite de se souvenir des emplacements des mailboxes pour: savoir dans quel mailbox placer une réponse, afficher les dernières mailboxes ouvertes, garder des bookmarks de mailbox.
Pour le moment je n'ai pas encore écrit une seule ligne de cette application (je n'ai pas encore trouvé un couple langage/toolkit convenable).
> Lire le journal (35 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #916280.
Run by 
Cette page a été générée par Templeet en 0.0669s (dont 0.006 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re:
Ça existe déjà :
[admin@ici ~]$ mkdir tmp
[admin@ici ~]$ cd tmp/
[admin@ici tmp]$ echo coucou > fichier
[admin@ici tmp]$ ln fichier alias
[admin@ici tmp]$ cat alias
coucou
[admin@ici tmp]$ mkdir rep
[admin@ici tmp]$ mv alias rep/
[admin@ici tmp]$ echo Bonjour >> rep/alias
[admin@ici tmp]$ cat fichier
coucou
Bonjour
[admin@ici tmp]$
Ça ne marche que sur un système de fichier. Mais pour un client mail c'est largement suffisant.
[+] [^]Re: Re:
n'est-ce pas l'inverse qu'aimerai faire Mildred ?
à savoir tu déplaces coucous mais alias pointe toujours dessus ... ?
[^]Re: Re:
Si tu laisses réfléchir à la question durant 3 ou 4 heures, je crois que j'arriverais à la conclusion que c'est aussi possible.
[^]Re: Re:
ln (sans -s) est parfaitement symétrique :
touch foo && ln bar foo ou touch bar && ln foo bar ont rigoureusement le même résultat.
Mr Lapinot - Electrons prisonniers (blog)
[^]Re: Re:
Merci MrLapinot, tu m'économises 3 bonnes heures de réflexion :-)
Plus précisément, car personne n'a la science infuse.
Voyons ce que ça donne avec le numéro d'inode :
[admin@ici tmp]$ touch toto
[admin@ici tmp]$ ls -i toto
125403389 toto
[admin@ici tmp]$ ln toto titi
[admin@ici tmp]$ ls -i toto titi
125403389 titi 125403389 toto # même inode
[admin@ici tmp]$ ln -s toto tutu
[admin@ici tmp]$ ls -i toto tutu
125403389 toto 125403390 tutu # inode différent
[admin@ici tmp]$ mv toto tata
[admin@ici tmp]$ ls -i tata
125403389 tata
[admin@one tmp]$ cat tutu
cat: tutu: Aucun fichier ou répertoire de ce type
toto (renommé tata par la suite) et titi ont le même inode, les noms pointent le même contenu. Il y a deux noms et qu'un fichier.
La commande mv, change le nom. Le inode reste donc le même.
Un lien symbolique est un fichier spécial avec un nom de fichier. Il ne se réfère pas au contenu (l'inode) mais à un nom. Donc lorsqu'on a changé le nom de toto, le lien symbolique pointe sur un fichier qui n'existe plus (d'où le "Aucun fichier ou répertoire de ce type").
Notons que la commande rm ne supprime pas un fichier (inode) mais un nom. S'il n'y a plus de nom qui référence un inode, alors le inode est supprimé.
D'ailleurs rm utilise unlink(2) : delete a name and possibly the file it refers to
[^]Re: Re:
Le problème des liens "durs", c'est que lorsqu'on tombe sur un fichier sur lequel on a précédement fait un lien, il n'y a (à ma connsaissance) aucun moyen de savoir où se trouve l'autre "exemplaire". Du coup il devient difficile d'effacer certains fichiers.
D'autre part on ne peut faire de liens entre 2 partitions, et on ne peut pas lier des répertoires...
Donc amha, il y n'existe pas de liens persistants réellement utilisable sous unix. Mais ça pourrait sans doute être implémenté assez facilement dans une surcouche du système de fichier, donc peut-être un travail pour Gnome ou KDE?
[^]Re: Re:
> c'est que lorsqu'on tombe sur un fichier sur lequel on a précédement fait un lien, il n'y a (à ma connsaissance) aucun moyen de savoir où se trouve l'autre "exemplaire".
[admin@ici tmp]$ touch toto
[admin@ici tmp]$ ln toto titi
[admin@ici tmp]$ ls -i titi
125403389 titi
[admin@ici tmp]$ rm titi
rm: détruire fichier régulier vide `titi'? y
[admin@ici tmp]$ find . -inum 125403389
./toto
Le problème est que ça peut être lent. Le find précédent doit être fait sur tout le système de fichier pour être sûr de retrouver le nom. Donc il faut fouiller tous les répertoires.
> et on ne peut pas lier des répertoires...
Si j'ai bonne mémoire, c'est possible mais que par le super-utilisateur. C'est possible et fortement déconseillé (je ne sais pas pourquoi).
> Donc amha, il y n'existe pas de liens persistants réellement utilisable sous unix. Mais ça pourrait sans doute être implémenté assez facilement dans une surcouche du système de fichier, donc peut-être un travail pour Gnome ou KDE?
C'est tout sauf simple.
Sur un système de fichier les liens hard marche très bien.
Sur différents systèmes de fichier c'est une autre histoire.
Exemple toto est un alias sur /media/usb/mon_fichier.
Et si je démonte /media/usb ?
Et si sur un autre système je fais "mv mon_fichier son_fichier" sur la clée usb ?
Ce n'est pas simple et c'est d'un intérêt très limité.
[^]Re: Re:
> Si j'ai bonne mémoire, c'est possible mais que par le super-utilisateur. C'est possible et fortement déconseillé (je ne sais pas pourquoi).
Parce que tu peux créer des cycles dans ton arborescence.
[^]Re: Re:
En fait, pour les dossiers, les liens 'hard' sont une mauvaise idée à cause des boucles. L'OS les gèrent pour nous au niveau des dossiers (faire ls -al et voir le nombre de lien par dossier).
Pour faire la même chose en mieux et éviter toute boucle dangereuse car pas mal de programme ne traverse pas les points de montage, il suffit de faire en root un
mount --bind
[^]Re: Re:
> [admin@ici tmp]$ find . -inum 125403389
[...]
> Le problème est que ça peut être lent.
Exactement. Vu la taille des disques actuels, c'est plutôt dissuasif.
> C'est tout sauf simple.
> Sur un système de fichier les liens hard marche très bien.
> Sur différents systèmes de fichier c'est une autre histoire.
> Exemple toto est un alias sur /media/usb/mon_fichier.
> Et si je démonte /media/usb ?
> Et si sur un autre système je fais "mv mon_fichier son_fichier" sur la clée usb ?
C'est bien pour ça que je parle d'une surcouche du système de fichier: la résolution de ce genre de situation demande généralement une interaction avec l'utilisateur ("Le fichier désigné par le lien "toto" est introuvable, voulez-vous lancer une recherche sur "/media/usb"?).
Je persiste à penser que les liens persistants pourraient être gérés au niveau des bibliothèques du desktop, à base de liens symboliques et d'attributs étendus.
Quand à l'intéret, c'est la liberté de déplacer ses fichiers sans avoir à réparer manuellement tous les raccourcis. Par exemple quand j'ajoute un répertoire dans la base de données de mon lecteur de musique préféré, j'aimerai ensuite être encore capable de le déplacer.
[^]Re: Re:
"Mais ça pourrait sans doute être implémenté assez facilement dans une surcouche du système de fichier, donc peut-être un travail pour Gnome ou KDE?"
KDE 4.1 (prévu pour juillet 2008) proposera en:Akonadi, qui permettra (entre autre) de centraliser les mails de l'utilisateur. On peut donc tout à fait imaginer que ce serait à lui de gérer ce que Mildred cherche à faire.