Je viens de stabiliser une toute première version du programme trsync. Il permet de synchroniser un dossier local avec un espace de partage Tracim. L'objectif : Travailler localement sur ses fichiers hébergés sur un un serveur Tracim et ne pas se préoccuper de la synchronisation.
Vidéo de démonstration : https://tracim.bux.fr/api/public/guest-download/cfe77068-7a30-4afb-8a54-ef4360039d82/TracimRemoteSync.webm
Pourquoi avoir commencé ce logiciel ?
J'aime et je promeus le logiciel libre. Je suis développeur. J'utilise à titre personnel Tracim pour gérer des documents personnels et professionnels de type documentation et Seafile pour un peu tout le reste (musique, photos, etc). J'avais envie depuis quelque temps de tout passer sur Tracim et le seul point bloquant pour mon usage était la synchro locale et « hors-ligne » de mes fichiers. Je me suis donc lancé dans ce projet. En plus, c'était l'occasion de faire du Rust \o/
Compiler et installer trsync
Pour compiler trsync, les étapes sont les suivantes :
- Installer Rust
- Installer les dépendances. Pour Debian like, cela se fait via la commande :
apt-get install build-essential pkg-config libssl-dev libsqlite3-dev
- Télécharger les sources de trsync : https://github.com/buxx/trsync/archive/refs/tags/v0.1.tar.gz
- Compiler :
cargo build
Le tester
Le projet est tout neuf, mais peu d'ores et déjà être testé. Vous pouvez par exemple l'essayer avec mon.tracim.fr (ou sur votre propre Tracim si vous en avez un).
Aujourd'hui trsync n'est dispo qu'en version de développement, donc il faudra nécessairement compiler vous-même le programme (cf section précédente)
Ensuite, pour tester, c'est relativement simple :
- Créer un compte ou se connecter sur https://mon.tracim.fr
Relever l'identifiant de l'espace partagé que vous voulez synchroniser
Lancer le processus de synchronisation depuis le dossier des sources (dans un terminal) :
cargo run /mon/dossier/Tracim/Test mon.tracim.fr 14 MonUserNameSurMonTracimFr
À noter que le processus est conçu comme un démon et si vous le laissez tourner il fera la synchronisation en temps réel en fonction de vos actions locales ou des actions réalisées par d'autres personnes sur le serveur
Comment ça marche ?
Tout le fonctionnement du programme repose sur les éléments suivants :
- Tracim propose une communication bidirectionnelle :
- une API REST permettant de faire des opérations sur le serveur (transmission d'informations du client vers le serveur)
- un socket SSE permettant d'être informé des opérations qui sont réalisés sur le serveur (transmission d'informations du serveur vers le client)
- trsync écoute le système de fichier local en s'appuyant sur inotify (ou équivalent selon le système d'exploitation)
- trsync gère un index local représentant l'état local et l'état distant.
Dans les grandes lignes, l'algorithme de trsync est le suivant :
- Au démarrage :
- Compare l'état des fichiers du dossier avec l'index
- Compare l'état des fichiers sur Tracim avec l'index
- Puis :
- Surveille les changements locaux (à l'aide de inotify par exemple)
- Surveille les changements sur Tracim (à l'aide des TLM introduits dans la version 3)
- Chaque changement donne suite à une résolution qui consiste à modifier les fichiers locaux ou sur Tracim tout en maintenant l'index local.
Comme évoqué précédemment, tout le fonctionnement repose sur les APIs standards de Tracim : API REST intégrées dans Tracim 2 et SSE intégrés dans Tracim 3 (tiens, d'ailleurs, on attend toujours la dépêche promise en janvier dernier au sujet de la nouvelle version ;)
C'est l'occasion de contribuer à un projet opensource et de vous mettre au Rust ;)
Pourquoi avoir choisi Rust ?
Parce qu'à mon avis et avec mes quelques années d'expériences sur ce langage, c'est le meilleur choix pour un programme que je souhaite aussi maintenable et stable que possible. Il est notamment très adapté dans le contexte de trsync pour les raisons suivantes :
- doit pouvoir être déployé sur des machines quelconques (Linux, Windows, MacOS)
- doit pouvoir évoluer vers une interface graphique - des bindings QT (entre autres) existent pour Rust
- travail nativement en exécution parallèle (envoi d'instructions sur le serveur Tracim en parallèle de l'écoute du socket SSE) -> Rust est idéal pour ça.
Let's go
Je suis preneur de toutes les idées, remarques et remontées de bugs ! Et bien sûr de toute contribution !
Pour celles et ceux qui souhaitent le faire directement sur la forge : https://github.com/buxx/trsync
# Super initiative ! :)
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 01 octobre 2021 à 10:52.
Le projet m'intéresse vivement (et pour cause : je suis le créateur de Tracim;)
Pourquoi avoir limité à un identifiant d'espace ? (s'il y a une autre raison que : "c'est la première étape)
À chaud, j'ai l'impression qu'une première requête d'API permettrait de récupérer la liste des identifiants d'espace et en conséquence de synchroniser l'ensemble.
Autre question : j'avais prévu/envisagé de faire un client (en python) s'intégrant à l'environnement graphique du client et en particulier l'espace de notifications. Est-ce que Rust permet de faire des lib dynamiques que l'on pourrait exploiter via un code en python ou autre ? Est-ce envisageable sur ce projet ?
Quelle est la manière la plus efficace aujourd'hui pour contribuer ? (sachant que je ne connais pas le langage Rust, j'imagine plutôt de contribuer autrement que sous forme de code)
C'est une super initiative je trouve !!!
[^] # Re: Super initiative ! :)
Posté par bux (site web personnel, Mastodon) . Évalué à 2.
Honnêtement je suis allé volontairement au plus simple pour commencer. En m'imaginant qu'un programme "au-dessus" s'occuperais de gérer un processus par espace partagé. Mais à ce stade, rien n'est figé.
Oui, je n'ai pas essayé mais c'est très en vogue !
Pourquoi pas :)
À mon avis : tester, remonter des bugs, bidouiller la CI de Github, réfléchir aux évolutions fonctionnelles et intégrations possibles.
Merci !
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
[^] # Re: Super initiative ! :)
Posté par xandercagexxx . Évalué à 2. Dernière modification le 01 octobre 2021 à 11:36.
Ça semble sympa ;)
Petites questions pratique :
En tout cas good job :)
[^] # Re: Super initiative ! :)
Posté par bux (site web personnel, Mastodon) . Évalué à 3.
Point du tout, trsync est vraiment ultra basique pour le moment. Les logs sont d'ailleurs assez affreux à ce stade :)
Non
Ca plante !
Oui (si tu parles du fait de modifier un fichier sur ton disque dur, qui produit une mise à jour de contenu sur Tracim).
non
--> Cet ensemble de questions fait une bonne liste de tickets de fonctionnalités :)
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
# Liste de fichiers ignorés, prise en charge des notes
Posté par raphj . Évalué à 4. Dernière modification le 01 octobre 2021 à 11:57.
Eh bien c'est parti ! :-)
.gitignore
pour Git. Une liste soit locale, soit synchronisée sur Tracim..document.html
mais ne permet pas de les modifier. L'extension pourrait être reprise, mais le comportement de la synchronisation pour ces fichiers devra appeler les API relatives aux notes (avec un éditeur de code ou un outil WYSIWYG indépendant de trsync qui ne s'occuperait que de la synchronisation elle-même).Félicitations pour ce projet.
[^] # Re: Liste de fichiers ignorés, prise en charge des notes
Posté par bux (site web personnel, Mastodon) . Évalué à 1.
Il y a même déjà un ticket pour ça https://github.com/buxx/trsync/issues/9 et https://github.com/buxx/trsync/issues/8
Je note !
Merci !
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
# Retour d'expérience
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Salut,
j'ai bossé il y a quelques années sur le client desktop de synchro de fichiers pour Cozy Cloud, et même si je n'ai plus les mains dedans, je continue de suivre les développements, les retours des utilisateurs, et de réfléchir à des idées pour l'améliorer. C'est probablement l'un des projets les plus difficiles sur lequel j'ai eu à travailler, mais aussi l'un des plus intéressants. J'ai écrit une note à ce sujet (en anglais) : https://github.com/nono/cozy-desktop-experiments/blob/main/RFC/Interest.md.
Au début, ça a l'air plutôt facile, on arrive facilement à faire un truc qui fonctionne en local. Puis, on le met entre les mains des utilisateurs, et on découvre plein de bugs. On les corrige, et on recommence. Et, après quelques itérations, on se rend compte que c'est un système distribué que l'on est en train d'écrire, et que faire un truc fiable dans ce domaine ne s'improvise pas. Mon principal regret est de ne pas avoir écrit un simulateur au début (c'est beaucoup plus compliqué à faire a posteriori quand la base de code commence à être grosse) : https://lobste.rs/s/igiolo/learning_build_distributed_systems#c_nlpl7r explique bien le principe.
Je conseille aussi fortement la lecture de ces 2 articles de Dropbox, sur la refonte de leur client (en rust) :
Bon courage ! Je vois que tu as commencé par Linux (tu parles d'inotify), c'est très bien, c'est l'OS le plus facile à mes yeux. Le système de fichiers est sensible à la casse, ce qui évite certains problèmes par exemple (HFS+ sur les anciens macOS fait de la normalisation unicode des chemins à l'aide d'un algorithme proche de NFD mais non standard, ça a nous a donné une tonne de bugs sur cozy-desktop).
Pour Linux, il faut faire attention à ne pas utiliser le numéro d'inode comme un identifiant de fichier de manière trop strict. Il y a 2 pièges à ça :
quelques logiciels passent par un fichier temporaire quand on sauvegarde (genre vim ou libreoffice) : ils créent une copie du fichier avec la nouvelle version, puis quand ils ont fini d'écrire, ils suppriment l'original et déplacent la copie à l'emplacement de l'original => c'est le même fichier aux yeux de l'utilisateur, mais le numéro d'inode a changé
les systèmes de fichiers réutilisent assez facilement les numéros d'inode :
foo
etbaz
sont 2 fichiers différents, mais ils ont eu le même numéro d'inode (juste pas en même temps).Voilà, j'espère que ça donne quelques pistes pour améliorer la fiabilité du trsync.
[^] # Re: Retour d'expérience
Posté par raphj . Évalué à 5. Dernière modification le 02 octobre 2021 à 18:52.
Oui. De plus, l'inode n'est unique qu'au sein d'un même système de fichier, donc si le dossier synchronisé contient deux points de montage, ce n'est pas bon.
Pire, certains systèmes de fichiers ne garantissent pas l'unicité des inodes. Pour Btrfs, par exemple, l'inode n'est unique que par sous-volume (avec le Copy-on-write, les fichiers peuvent être partagés jusqu'à la modification… et d'ailleurs, la modification d'un fichier peut aussi le faire changer d'inode). Et une partition Btrfs peut être montée entièrement sur un unique point de montage, avec tous les sous-volumes dedans.
Je suppose que c'est vrai aussi pour ZFS.
Donc ça peut causer des bugs « intéressant » effectivement, et la solution de n'accepter de synchroniser des fichiers n'appartenant qu'à un seul point de montage n'est pas suffisante.
[^] # Re: Retour d'expérience
Posté par bux (site web personnel, Mastodon) . Évalué à 6.
Merci pour ce retour d'expérience ! Il me sera très précieux !
J'ai évité d'utiliser le numéro d'inode : Initialement pour palier aux éventuels déplacements d'une partition vers une autre (ou dans le genre). Je me suis évité des problèmes on dirait :)
J'ai effectivement constaté ce comportement (création d'un fichier intermédiaire puis renommage) et dû gérer le cas …
J'espère que je tiendrais le coup ^
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.