Journal Liens symboliques persistants ??? Idée de workflow pour les e-mails.

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
mar.
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).

  • # liens directs

    Posté par  . Évalué à 10.

    Tu n'as qu'à créer des liens directs tout simplement (en utilisant ln sans -s). « man ln » pour en savoir plus.

    • [^] # Re: liens directs

      Posté par  . Évalué à 1.

      comment tu fais ça sous X11 ?

      • [^] # Re: liens directs

        Posté par  . Évalué à 10.

        avec xterm ?

        • [^] # Re: liens directs

          Posté par  . Évalué à 4.

          Non, mais avec konqueror ou galeon ou autre navigateur de fichiers ?
          Car, sous MacOS X, c'est possible avec le navigateur de fichier.
          Je maitrise bien la ligne de commande, mais je me mets à laplace d'un neophyte o ud'un type qui est rebuté par les term

          • [^] # Re: liens directs

            Posté par  . Évalué à 1.

            Pour konqueror ça peut surement se faire facilement avec un service menu.

            Il y a peut-être (j'ai la flemme de chercher) déjà un truc équivalent dans le paquet disponible sur kde-apps:
            http://kde-apps.org/index.php?xcontentmode=287

            • [^] # Re: liens directs

              Posté par  . Évalué à 1.

              Oui, mais je te demande "from scratch" comme c'est le cas sous macintosh..

              • [^] # Re: liens directs

                Posté par  . Évalué à 2.

                Je ne comprend pas ta remarque.
                Si tu veux le faire "from scratch" ben l'appel système link est là
                http://www.linuxmanpages.com/man2/link.2.php

                • [^] # Re: liens directs

                  Posté par  . Évalué à -1.

                  click droit / copier
                  click droit / créer un lien ---- symbolique ou dur
                  Bref, j'installe linux, et la première chose que je veux faire est de créer un lien symbolique et un lien dur sans rédiger une ligne de shell: est ce possible de le faire sans installer de service menu tiers ?

                  • [^] # Re: liens directs

                    Posté par  (site web personnel) . Évalué à 1.

                    À la base c'était pas pour écrire une application ?
                    Et sinon, habituellement sur une installation linux fraîche on n'a pas X11 et je ne connais pas de wrapper pour "ln" en curses et gpm qui soient présents sur un système de base.

                    • [^] # Re: liens directs

                      Posté par  . Évalué à 1.

                      Oui, mais c'est une question ue je me pose, mais vu le peu de réponse que j'ai ,cela n'est le cas poru aucune distribution, donc ma mandriva n'est pas en retard sur ce point.
                      N'empêche que parfois, j'aimerais créer des liens en restant dans mon instance konqueror et sans avoir besoin d'ouvrir mon yakuake (bien meilleur que xterm soit dit en passant). Mais bon, cela semble impossible.

                      • [^] # Re: liens directs

                        Posté par  (site web personnel) . Évalué à 3.

                        Sélection du fichier avec le bouton gauche, drag'n'drop là où tu veux créer le lien, dans le menu contextuel qui s'affiche sélection de "Lier ici".

                        Tout ça sous Konqueror.

                        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                        • [^] # Re: liens directs

                          Posté par  . Évalué à 2.

                          ça fait un lien symbolique, pas un lien dur

                    • [^] # Re: liens directs

                      Posté par  (site web personnel) . Évalué à 2.

                      Et sinon, habituellement sur une installation linux fraîche on n'a pas X11 et je ne connais pas de wrapper pour "ln" en curses et gpm qui soient présents sur un système de base.
                      Il y a longtemps que cela dépend de la distribution Linux dont on parle et que cette époque du tout texte est révolue.

    • [^] # Re: liens directs

      Posté par  (site web personnel) . Évalué à 1.

      entre différents systèmes de fichiers c'est ... on va dire un peu dur. Si tu sais comment faire je veux bien.

      Si tu sais comment faire des liens en dur pour des dossiers sans être root, je veux bien aussi.

      • [^] # Re: liens directs

        Posté par  (site web personnel) . Évalué à 1.

        Des liens en durs pour des dossiers, root ou pas root, c'est pas possible.

        Par contre, tu peux regarder du coté de "mount --bind". Bon, il faut être root...

        • [^] # Re: liens directs

          Posté par  . Évalué à 2.

          si t'es prêt à faire du mount, tu peux faire avec "fuse" pour le faire en utilisateur (mais faut activer fuse et tout)

  • # Re:

    Posté par  . Évalué à 7.

    Ç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:

      Posté par  . Évalué à -1.

      n'est-ce pas l'inverse qu'aimerai faire Mildred ?
      à savoir tu déplaces coucous mais alias pointe toujours dessus ... ?

      • [^] # Re: Re:

        Posté par  . Évalué à 2.

        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:

        Posté par  (site web personnel) . Évalué à 7.

        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.

        • [^] # Re: Re:

          Posté par  . Évalué à 7.

          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:

          Posté par  . Évalué à 2.

          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:

            Posté par  . Évalué à 3.

            > 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:

              Posté par  . Évalué à 3.

              > 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:

                Posté par  (site web personnel) . Évalué à 1.

                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:

              Posté par  . Évalué à 2.

              > [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:

            Posté par  . Évalué à 2.

            "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.

  • # do you git it ?

    Posté par  (site web personnel) . Évalué à 4.

    en fait ce que tu souhaiterais, c'est une sorte de base de "blob" contenant tes mails et leurs headers et que tu puisse à ta guise construire des arborescences de ces blobs au fils du temps, des filtres et des tes actions ?

    En fait, à part réinventer la roue^W^W GIT, je ne vois pas comment faire autrement.

    tu peux faire de la merde via des hard-links & co, tu peux passer par une bdd qui représentera un over-head très couteux quand tu auras un beau volume de mail, tu peux inventer plein de technos funs ...

    ... mais j'ai le sentiment que git fait ce que tu cherches.

    En fait, si je devais coder un client mail, je coderai en premier lieu, une interface graphique qui "git-add" les nouveaux mails dans un dossier inbox, "git-mv" dans les différents dossiers, "git-rm" pour la mise à la corbeille, et enfin "git-gc" pour faire le garbage collecting et la refacto des l'arbo. ... après tu peux ajouter le deplacement de l'origine pour le really "expunge" de tes mails et ne garder que les derniers effacés et ceux que tu souhaites bien entendu conserver :)

    • [^] # Re: do you git it ?

      Posté par  (site web personnel) . Évalué à 5.

      L'abus de git est dangereux pour la santé (mentale).

      • [^] # Re: do you git it ?

        Posté par  . Évalué à 5.

        Pour la santé tout court : Claude François a tripoté sa lampe, ça a fait git giiit.

        ⟶[]

        • [^] # Re: do you git it ?

          Posté par  . Évalué à 3.

          Le jour de la mort de Claude François est un de ce rare jour où un service public, EDF, a vraiment rendu service au public.


          Désolé ;)

    • [^] # Re: do you git it ?

      Posté par  (site web personnel) . Évalué à 1.

      Je ne connais pas en détail git, mais le but c'est que les mails puissent être dispatchés dans tout le homedir de l'utilisateur. Rangé par l'utilisateur. Voire même sur des disques externes.

      Le but c'est de sortir de la situation actuelle ou tous les e-mails sont a un seul endroit (chez moi ~/Mail, ailleurs ~/.thunderbird ou ~/.evolution ...) Que l'utilisateur puisse manipuler ses mails a loisir avec son navigateur de fichiers.

      Donc je vois mal utiliser git ... a moins que tu ne veuilles intégrer git dans le système de fichiers en lui même.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.