Journal faire le ménage dans son $HOME, je n'ai presque plus de fichiers cachés !

Posté par  .
Étiquettes : aucune
0
10
août
2006
Suite d'un vieux journal : http://linuxfr.org/~lucd/17947.html

après avoir pris en compte les quelques remarques des commentaires, j'ai enfin pris le temps de faire un tar.gz et de publier ça:
http://ordiluc.net/fs/libetc/

Le code fonctionne bien pour moi, et je n'ai plus que quelques fichiers commençant par un '.' dans mon répertoire personnel (par ex .zshrc et .xsession).

  • # c'est bien ton truc....

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

    heu, meme tellement que ça devrait etre par defaut dans les distribs modernes :)

    • [^] # Re: c'est bien ton truc....

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

      Ben t'a plus qu'a te lancer dans la création d'un package Ubuntu alors...

    • [^] # Re: c'est bien ton truc....

      Posté par  . Évalué à 3.

      effectivement cela à l'air extra. Est-ce que tu vas essayer de faire pression pour que ce genre de fonctionnalité soit inclu dans la plupart des distributions actuelles ?
      Est-ce qu'il y aurait des raisons pour ne pas vouloir l'adopter ?

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: c'est bien ton truc....

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

        Tu me pretes un pouvoir que je n'ai pas :/ j'ai des contacts aupres d'un certain nombre de contributeurs, parfois important, mais pas du tout au niveau des distribs elle-meme.

        Je crois que l'auteur du script devrait plutot s'arranger pour qu'il soit associé a la spec, sur le site de freedesktop lui meme, et contacter les mailing lists de développement des distribs. Mieux: Qu'il propose en plus directement à celles ci des patchs pret a commiter.
        C'est le genre de méthode qui a tendance a marcher si les projets sont ouverts.

  • # question

    Posté par  . Évalué à 3.

    Zut alors, j'ai loupé le premier épisode de ton journal.
    Je me demande si ce ne serait pas possible de faire la même chose avec lufs. Je dis peut-être une grosse connerie mais il me semble avoir lu sur lwn qu'il était maintenant possible de faire des bind-mount à la plan9 avec linux. Enfin c'est une piste à investiguer qui est peut-être moins contraignante qu'un ld_preload (par ex si on veut utiliser un autre ld_preload).
    Ça pourrait aussi être une idée de plugin intéressant pour reiser4.

  • # Hum...

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

    Donc si je comprends bien, tu as des bazillions de fichiers cachés dans ~/.config/, au lieu de les avoir dans ~ ?

    Ça n'apporte aucune classification, aucun ordre, aucun groupement supplémentaire (à la ~/.kde par exemple, qui regroupe les fichiers cachés de toutes les applications KDE) et étant donné le caractère caché des fichiers, j'avoue avoir bien du mal à cerner l'utilité de la chose.

    [Merci de faire semblant d'attendre que je lise l'ancien journal...]

    Bon, ça semble avoir été écrit pour palier les problèmes des applications gtk/gnome incapables de gérer correctement les fichiers cachés...

    Je reste réellement curieux de savoir ce que ça apporte en pratique.

    • [^] # Re: Hum...

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

      Les fichiers ~/.machinbidule, c'est mal.

      Comment tu fais un backup de tes fichiers de config sans sauvegarder ton $HOME -> c'est la merde, alors que sinon, tu as un répertoire à sauvegarder.

      Comment tu fais une synchro de tes fichiers de config entre plusieurs machines ? -> C'est la merde. Si t'as tout dans un répertoire, c'est un jeu d'enfant avec n'importe quel gestionnaire de version ou une solution genre unison.

      Sans parler du bazar que c'est avec pas mal d'applies graphiques pour gérer les fichiers cachés. Par exemple, il y a quelques années, j'avais essayé d'expliquer à ma soeur comment sauvegarder son ~/.mozilla (i.e. en particulier ses mails) avec K3B, bah elle a jamais réussi. Ça s'est amélioré depuis.

      D'après toi, quel est le bénéfice d'avoir tout les fichiers de configuration du système dans /etc/ à la place de les avoir direct dans / ? Bah, là, c'est pareil.

      Perso, j'utilise une solution similaire depuis quelques années : mes ~/.quelquechose importants sont tous des liens symboliques vers ~/etc/quelque-chose. J'attends avec impatience que les développeurs se mettent à la norme freedesktop du ~/.config/.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Hum...

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

          Oui, tu peux, mais je trouve quand même vachement plus pratique de copier un répertoire. Par exemple, un sénario typique :

          $ cp -r .* backup/
          $ cd backup/
          $ ls
          $ <oh, merde, y'a rien ici ??? j'étais persuadé d'avoir fait une sauvegarde>

          Un répertoire, tu peux faire un

          $ tar czf etc.tar.gz etc/

          et tu as une belle archive, quand tu la détarre, il te met les fichiers dans le répertoire (j'ai horreur des archives tar qui me pourrissent mon répertoire local).

          Ceci dit, le vrai problème, c'est que les ~/.quelquechose sont mal rangés. Par exemple, à l'heure où je parle, j'ai ça :

          $ du -sh ~/.thumbnails/ ~/etc/emacs.el
          93M /home/moy/.thumbnails/
          44K /home/moy/etc/emacs.el (~/.emacs.el est un lien qui pointe dessus)

          Quand je fais une sauvegarde, j'ai bien envie que mon emacs.el soit sauvegardé, mais pas envie du tout de me trimballer les 100Mo de mon .thumbnails/. Si tout ça était effectivement bien classé, avec le cache reconstructible d'un côté et les fichiers de conf de l'autre, on n'aurait pas ce problème. Et malheureusement, la solution proposée dans le journal ne résoud pas ça.

          • [^] # Re: Hum...

            Posté par  . Évalué à 4.

            Quand je fais une sauvegarde, j'ai bien envie que mon emacs.el soit sauvegardé, mais pas envie du tout de me trimballer les 100Mo de mon .thumbnails/. Si tout ça était effectivement bien classé, avec le cache reconstructible d'un côté et les fichiers de conf de l'autre, on n'aurait pas ce problème. Et malheureusement, la solution proposée dans le journal ne résoud pas ça.

            La solution consisterait à séparer un $HOME/etc et un $HOME/var. La libetc devrait, de là, choisir en fonction du type de fichier sauvegardé (le plus simple étant de faire à partir d'une base de données tirée des spécifications de fd.o) s'il s'agit plutôt d'un candidat à etc ou à var.

            • [^] # Re: Hum...

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

              ca peut meme etre les 2. Prenons aMule comme exemple:
              Dans .aMule, il y a la conf (etc donc), mais aussi le répertoire Temp (qui devrait etre dans var) ainsi que Incoming (var, voir caremment $HOME)

              C'est le genre de truc qui devrait etre vu avec les teams des projets concernés. Je vois bien ce script comme "transition", mais il faudrait bien que les softs fasse le boulot.

              Je regarderai ce qui est en train d'etre fait pour KDE4, par curriosité

            • [^] # Re: Hum...

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

              une autre solution consisterait à enrichir libetc et lui passer un fichier de configuration (à placer dans $HOME/.libetc $XDG_CONFIG_HOME/.libetc par exemple) où tu définis via des expressions régulières où tu souhaites que soient redirigés tes fichiers

          • [^] # Re: Hum...

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

            J'oubliais ;-).

            .*, c'est bien, mais ça n'est que pour la ligne de commande. Avec les GUI classiques, selectionner tous les fichiers cachés et pas les autres, c'est une opération assez compliquée ...

        • [^] # Re: Hum...

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

          omment tu fais un backup de tes fichiers de config sans sauvegarder ton $HOME

          .* ?


          Raté.

          theocrite@riemann$ ls -d .*
          .
          ..
          .aptidude
          [snip]



          theocrite@riemann$ cp -r .* backup/
          cp: cannot copy a directory, `.', into itself, `backup/.'
          cp: cannot copy a directory, `.', into itself, `backup/.'
          cp: cannot copy a directory, `.', into itself, `backup/.'
          cp: cannot copy a directory, `.', into itself, `backup/.'

          • [^] # Re: Hum...

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

            Tiens, c'est marrant, j'allais répondre ça, et j'ai fait le test par acquis de conscience, et .* ne matchais pas .. et . . En fait, c'est juste mon zsh qui fait ça.

            Anecdote amusante :

            C'est l'histoire d'un sysadmin qui met un "rm /tmp/*" dans un cron qui tourne en root. C'est l'histoire d'étudiants qui rangent soigneusement leurs données dans /tmp/./ pour contourner la politique de quotas.

            Et après, c'est l'histoire d'un sysadmin qui change le "/tmp/*" en "/tmp/* /tmp/.*".

            • [^] # Re: Hum...

              Posté par  . Évalué à 5.

              Dans un autre style, c'est l'histoire d'étudiants qui travaillèrent toute une journée dans /tmp plutôt que sur leur /home monté en NFS sur un réseau passablement engorgé. C'est l'histoire d'une machine qui plante honteusement au beau milieu d'une compilation un peu lourde, et qui est réputée pour vider le /tmp à chaque démarrage.

              Et après, c'est l'histoire d'étudiants qui font une expérience digne de feu-Schrödinger, leur précieux code étant ni vraiment disparu, ni vraiment encore là. Reboot or not reboot, that used to be the question.

              • [^] # Re: Hum...

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

                Il y a /goinfre pour ça.

                • [^] # Re: Hum...

                  Posté par  . Évalué à 2.

                  Damn, grillé :)

                  Trêve de private, je ne me souviens plus pourquoi cette histoire avait fini dans le /tmp, mais alors il y avait eu des pleurs et des grincements dedans. En tous cas, il y avait forcément une bonne raison, on n'était pas si cons en ce temps-là, quand même.

                • [^] # Re: Hum...

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

                  Et les live-CD pour booter sans monter /tmp tout de suite !

                  /var/tmp/ est aussi en principe plus persistant que /tmp

  • # Patch ?

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

    Y'a des trucs qui me plaisaient pas dans le code, alors j'ai fait un petit patch.
    Théoriquement, ça devrait rendre tout ça plus rapide (les static aident gcc a optimiser, et un malloc en moins, c'est toujours ça de pris, idem pour le strdup).
    J'ai testé, ça semble marcher.
    http://iksaif.ath.cx:81/~iksaif/libetc.patch

    • [^] # Re: Patch ?

      Posté par  . Évalué à 3.

      Merci, je vais incorporer ça dans la prochaine version. Je suis loin de faire du C tous les jours. Je prend tout ce qui améliore le code !

    • [^] # Re: Patch ?

      Posté par  . Évalué à 1.

      l'url ne fonctionne plus, est-ce que quelqu'un a encore ce patch?

Suivre le flux des commentaires

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