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) :
doit pouvoir être déployé sur des machines quelconques (Linux, Windows, MacOS)
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 :
# Retour d'expérience
Posté par Bruno Michel (site web personnel) . En réponse au journal trsync : un outil de synchronisation bidirectionnelle pour travailler hors-ligne avec tracim. É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 :
fooetbazsont 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.