En parcourant ce journal, j'ai constaté qu'il existait une demande pour un logiciel libre permettant de rapporter les modifications intervenues sur un ensemble de fichiers. Or, le framework avec lequel je travaille étant pourvu de fonctionnalités permettant de récupérer assez facilement des information sur des fichiers ou des répertoires, c'était là l'occasion, pour moi, d'apporter une (autre) pierre à l’édifice du Libre en développant un tel logiciel.
Voici donc une première version de ce logiciel. Je ne vais pas trop entrer dans les détails, car il ne s'agit là que d'un premier jet, visant à valider les bases. En outre, à l'usage, la manière dont j'ai implémentée certaines fonctionnalités ne se révélera probablement pas la plus pratique, et nécessitera certainement d'être remaniée, en fonction des retours d'utilisateurs intéressés par ce logiciel ; un des buts de ce journal est d'ailleurs d'obtenir de tels retours.
Cette version du logiciel implémente les commandes suivantes (la commande --help permet d'en voir la liste explicative) :
- --browse : affiche ou écrit dans un fichier le contenu d'un répertoire ; cette commande permet de tester les performances de base du logiciel dans différents contextes,
- --update : crée ou met à jour les données servant à la détection des modifications ; cette commande place un certains nombre de marqueurs dans l'arborescence surveillée,
- --compare : affiche ou écrit dans un fichier les modifications opérées sur les répertoires (suppression, renommage, déplacement, création) et les fichiers ; dans cette version du logiciel, la détection des ces modifications ne s'appuie que sur la taille et l'horodatage, mais d'autres éléments pourront être pris en compte dans les futures versions,
- --clean : supprime les données servant à la détection des modifications crées par la commande --update.
Ce logiciel est diffusé sous licence publique générale GNU Affero, et tourne sous GNU/Linux (et probablement sur la plupart des systèmes POSIX), OS X, et Windows, nativement sur architecture IA-32, AMD64 et ARM.
Toutes les ressources concernant ce logiciel sont disponibles à cette adresse : http://q37.info/computing/epeios/tools/fwtchrq/.
# Je trouve que le nom est trop facilement prononçable ...
Posté par totof2000 . Évalué à 10.
Tu pourrais pas le changer ? ;)
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par martoni (site web personnel, Mastodon) . Évalué à 1.
Ça me fait penser à un gag dans Kid paddle cherchant à faire un mot au scrabble ;)
J'ai plus qu'une balle
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par Claude SIMON (site web personnel) . Évalué à -2.
L'ennui avec les noms de logiciels, comme avec les noms de domaines d'ailleurs, c'est que, si vous arrivez à en trouver un qui soit assez court, évocateur, joli (quoique l'on puisse entendre par ce terme ; la prononçabilité, par exemple), facile à retenir, etc., et bien, il y des chances que ce nom, ou une forme proche, soit déjà utilisé. Le risque existe alors d'avoir un jour à le changer, avec tous les désagréments que cela implique (modification de tous les documents comportant ce nom), sous peine de risquer un conflit avec une quelconque entité qui utilise un vocable qui présente, ne fût-ce que vaguement, des similitudes avec le nom en question pour désigner l'un de ses produits. C'est déjà arrivé à plus d'un logiciel.
Par ailleurs, je référence mes logiciels sur différents sites, à l'instar, par exemple, de xppq, qui est référencé sur Savannah et Freshcode, pour ne citer que ces deux-là. Pour pouvoir référencer son logiciel sur l'un de ses sites, il faut lui affecter un identifiant unique, et il est pratique alors d'utiliser le nom même du logiciel, comme cela est visible dans les URL ci-avant, plutôt que d'avoir à en trouver un autre, et à devoir se le rappeler, pour chaque site pour lequel cet identifiant est déjà utilisé.
fwtchrq n'est pas le premier logiciel (et, j'espère, pas le dernier non plus) libre que je développe. Et je n'ai pas envie, à chaque fois que j'entreprends de développer un nouveau logiciel, de perdre des heures à chercher un nom qui soit assez court, évocateur, joli, facile à retenir, etc., puis à devoir vérifier qu'il, ou une forme proche, ne soit pas déjà utilisé, découvrir qu'il l'est déjà et avoir à en chercher un autre je ne sais combien de fois, tout en n'ayant jamais la certitude d'avoir poussé mes recherches suffisamment loin pour avoir définitivement écartée l'épée de Damoclès.
Bref, les noms de mes logiciels semblent peut-être biscornus, mais c'est le prix à payer pour avoir une probabilité raisonnablement forte de n'avoir jamais à les changer…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par groumly . Évalué à 10.
Non, mais bon, appeler ton outil file-watcher (je suppose que c'est ce que ca veut dire), ca aurait tue personne.
Idem pour la plupart du code, des fichiers nommes dwtdct.cpp, ca aide pas.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par karteum59 . Évalué à 2.
ça aurait pu avoir du sens si c'était du code implémentant la DCT et la DWT, mais j'ai pas trop l'impression que ce soit le cas… :)
[^] # Re: Je trouve que le nom est trop facilement prononçable ...
Posté par totof2000 . Évalué à 9.
Tu devrais lire le livre "coder proprement". Ca te ferait probablement changer d'avis. Sinon, pour ton info, un nom, c'est vraiment pas un truc à choisir à la légère. Imagine-toi un mec dans un bureau essayer de conseiller ton soft à son collègue :
- Essaie un peu fwtchrq, ça t'aidera
- frcht quoi ?
- "Effe Doublevé té cé hach erre ku"
- ???? Tant pis j'utilise pas.
# Change de nom !
Posté par Sébastien Rohaut . Évalué à 10.
Salut, j'interviens rarement, mais à mon humble avis, rien qu'à cause du nom personne ne se rappellera de ta commande, aussi bonne soit-elle…
[^] # Re: Change de nom !
Posté par Claude SIMON (site web personnel) . Évalué à -2.
Voir ce commentaire.
Pour nous émanciper des géants du numérique : Zelbinium !
# Tu pourrais pas mettre un dépôt Git ?
Posté par HLFH . Évalué à -4.
Tu peux mettre en place un dépôt Git avec Gogs ou le service de Framasoft.
[^] # Re: Tu pourrais pas mettre un dépôt Git ?
Posté par Claude SIMON (site web personnel) . Évalué à 10.
Quel est l'intérêt ? De ce que j'en connais, Git est un logiciel de gestion de version ; or, dans la page dédié à fwtchrq, il y a les liens vers un dépôt Mercurial hébergé sur Savannah contenant les sources de fwtchrq…
Pour nous émanciper des géants du numérique : Zelbinium !
# Quelques questions
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Intéressant ! Je travaille sur un logiciel de synchronisation de fichiers et un des composants importants de ce projet est la surveillance d'une arborescence de fichiers, ce que
fwtchrqa l'air de faire. Du coup, je me pose quelques questions sur son fonctionnement :Est-ce que les modifications d'un fichier sont aussi détectées ?
Est-ce qu'il utilise inotify, fsevents et consorts pour suivre les modifications ? Ou c'est "juste" un parcours de l'arborescence de temps en temps pour voir les modifications ?
Est-ce qu'il y a du code un peu particulier pour éviter les race conditions ? Par exemple, il arrive d'avoir un événement "suppression" avant l'événement "création" quand un fichier est déplacé avec inotify ou fsevents (je ne sais plus lequel des deux).
Comment est géré le cas où deux fichiers sont permutés (
mv a c && mv b a && mv c b) ?Est-ce qu'il est possible d'ignorer une partie de l'arborescence ? Si oui, est-ce que les marqueurs de détection sont quand même placés ? Et, toujours si oui, ça se passe comment quand la liste d'exclusions change en cours de route ?
[^] # Re: Quelques questions
Posté par Yth (Mastodon) . Évalué à 2.
inotify et fsevents étant spécifiques à Linux, je suppose qu'il s'agit d'autre chose.
Yth.
[^] # Re: Quelques questions
Posté par Bruno Michel (site web personnel) . Évalué à 4.
inotify est spécifique à Linux. Par contre, il y a des équivalents sur les autres OS : fsevents pour OSX, kqueue pour les BSD et un truc avec un nom bien long sous windows.
[^] # Re: Quelques questions
Posté par xcomcmdr . Évalué à 1.
ça https://msdn.microsoft.com/en-us/library/windows/desktop/aa365261%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques questions
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Oui, c'est ça :
ReadDirectoryChangesW.[^] # Re: Quelques questions
Posté par BAud (site web personnel) . Évalué à 4.
Pour de la réplication de fs, tu peux aussi regarder vhffs-fssync :
http://www.vhffs.org/doc:installationguide:misc-vhffsfssync
C'est utilisé sur TuxFamily.org pour envoyer ce qui est uploadé par un utilisateur (via ftp, scp, rsync…) vers les CDN utilisés pour les download repositories.
gradator< y avait consacré pas mal de temps pour gérer tous les cas (fichiers .part, renommage intempestif, limitation de l'utilisation de bande passante, priorisation des petits fichiers…). Une discussion sur inotify : http://www.gossamer-threads.com/lists/linux/kernel/1421191
Le code est disponible sur http://svn.tuxfamily.org/viewvc.cgi/vhffs4_vhffs/trunk/vhffs-fssync/
[^] # Re: Quelques questions
Posté par Claude SIMON (site web personnel) . Évalué à 4.
fwtchrq se contente de parcourir l’arborescence et d'en comparer le contenu avec une image qu'il en a faite lors d'un précédent lancement. De par les marqueurs qu'il place dans l’arborescence surveillée, il est capable de détecter les créations/renommages/déplacements/suppressions de répertoires. Par contre, concernant les fichiers, vu qu'il s'appuient uniquement sur leur taille et leur horodatage, il rapportera le renommage d'un fichier, par exemple, comme une création et une suppression de fichiers. Pour les mêmes raisons, une permutation de fichiers sera, à priori, rapporté comme une modification de chacun des fichiers
inotify serait, à priori, un bon outil pour détecter un renommage de fichier. Toutefois, j'ai essayé
inotifywatch -rsur mon arborescence de test, qui est extrêmement fournie : c'est lent, et, en outre, il n'a pas été en mesure d'aller jusqu'au bout faute d'un nombre suffisant de inode watches. Je suis donc, pour l'instant, dubitatif quand à l'intérêt de cet outil dans le cadre du développement de fwtchrq.Il y une gestion des exclusions, que l'on spécifie à l'aide d'un fichier, tel que celui que l'on trouve à l'adresse : http://hg.savannah.gnu.org/hgweb/epeios/file/70ebcb4eaa50/tools/fwtchrq/Exclusions.txt. Le fichier d'exclusion à utiliser et à spécifier dans le fichier de configuration, comme on peut le voir à cette adresse (la section en question est en commentaire) http://hg.savannah.gnu.org/hgweb/epeios/file/70ebcb4eaa50/tools/fwtchrq/fwtchrq.xcfg. Lorsqu'un répertoire est exclu, il est vraiment totalement ignoré par le logiciel.
Comme indiqué dans le journal, il ne s'agit là vraiment que d'un tout premier jet. Ce logiciel peut évoluer dans n'importe quelle direction (utilisation de inotify sous GNU/Linux et équivalent pour les autres systèmes, prise en compte d'autres critères que la taille et l'horodatage pour les fichiers, configurabilité de la gestion des exclusions…), pour peu que la demande soit telle que cela vaille la peine pour moi d'y investir le temps nécessaire…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Quelques questions
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Merci pour les réponses. Je ne compte pas utiliser fwtchrq, mais c'est intéressant de savoir comment il fonctionne.
Ça se configure assez simplement : https://github.com/cozy-labs/cozy-desktop/blob/master/doc/inotify.md
Pour les exclusions, il y a raison particulière de ne pas avoir utilisé le même format que gitignore ? Là, le format où
tmpsignifie en fait un fichier avec une extension.tmp, je trouve ça assez déroutant.[^] # Re: Quelques questions
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Tout simplement le fait que j'ignorais l'existence de gitignore. Bref, ce n'est pas un format que j'ai exclu sciemment…
Comme pour toutes les autres fonctionnalités du programme, j'ai juste implémenté la première mise en œuvre qui me passait par la tête (pour faire court). Le
tmpéquivalent à.tmp, c'est juste une facilité que j'ai rajoutée car facile à coder. Maintenant, il faut voir ce que tout cela donne à l'usage, et affiner/modifier en conséquence…Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Quelques questions
Posté par steph1978 . Évalué à 2. Dernière modification le 17 décembre 2015 à 20:30.
Je voulais mettre en place de la sauvegarde incrémentale sur une arborescence. J'ai eu le même problème avec les limitations de inotify : le lancement sur une grosse arborescence est infiniment lent et dépasse bien souvent la limite du nombre de watcher.
Bien souvent tu veux surveiller tout un répertoire (/data). Mais pour cela le noyau doit placer un watch sur chaque fichier et répertoire de l'arborescence, récursivement. Il n'a pas la notion d'appartenance d'un fichier ou répertoire à une arborescence. Ça ne passe pas bien à l'échelle.
Il faudrait un mécanisme dans le noyau qui permette de surveiller une arborescence.
Cela pénalise un peu le "open", il faut inspecter chaque noeud parent, mais après ce serait très rapide. Et la mise en place serait instantanée : seulement un watcher sur la racine.
En attendant, je réfléchis à un mécanisme similaire utilisant FUSE.
[^] # Re: Quelques questions
Posté par claudex . Évalué à 3. Dernière modification le 17 décembre 2015 à 21:06.
Pourquoi ne pas mettre un watcher par dossier ? Ça augmente le temps de mise en place mais ça diminue la charge à chaque open.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques questions
Posté par steph1978 . Évalué à 2.
Je pense que tu veux dire mettre un watcher par dossier pour tous les dossiers d'une arborescence, c'est ça ?
Cela ne changera pas vraiment le problème car le dossier représentent bien souvent une part non négligeable. en supposant que tu as 50k dossier pour 150k fichiers tu ne réduis ta problématique que par 4. En plus, sans être spécialiste inotify, si tu as beaucoup de fichiers dans un répertoire, tu aura plusieurs inodes pour le décrire et donc plusieurs watcher à placer (je ne suis pas sûr de ça).
Mon idée est plutôt de créer un mécanisme qui, quand tu ouvre le fichier "/a/b/c/d", se dit, est ce qu'il y a un watcher sur d ? non ; sur c, non ; sur b ? non ; sur a, oui ! Donc le fichier est surveillé.
Ça pénalise le open, mais sur un FS dédié aux données et qui subira une surveillance, le jeu en vaut la chandelle.
[^] # Re: Quelques questions
Posté par claudex . Évalué à 3.
Oui, c'était bien ça. Mais ton radio de 1 pour 4 me semble faible, j'aurais plutôt dis 1 pour 10.
Imaginons que ce soit un dossier partagé utilisé dans le cadre du travail p par plusieurs personnes et qu'on le surveille pour le sauvegarder, je ne dis pas sûr que pénaliser les open en valle la chandelle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques questions
Posté par steph1978 . Évalué à 2.
Tout à fait, cela dépend de l'usage.
Reste que je constate que inotify est peu scalable.
Et un fullscan peu fiable et très impactant pour les performance.
Il y a donc une place pour un autre mécanisme imho.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.