Je n'ai pas fais de vérification mais pour que des logiciels de synchronisation aient une chance de fonctionner il faut qu'ils traquent les close et move via inotify plutôt que de faire la copie bêtement.
Je confirme, c'est l'idée. C'est bien entendu plus compliqué que ça (FsWatcher, l'équivalent de inotify pour macOS n'a pas d'événements pour les close par exemple), mais en gros, ça revient à écouter les changements sur une partie de l’arborescence, et quand un fichier change, on attend un peu après les derniers changements, puis on va lire progressivement le fichier et envoyer ça au serveur.
Si non tu ne peux pas non plus t'en servir pour les fichiers LibO par exemple et ça commence à être problématique car c'est un peu leur cas d'usage principale.
En général, la plupart des logiciels gardent les documents des utilisateurs ouverts (au sens avec un file handler) pendant des périodes de temps très courtes. Au moment où ils font la sauvegarde, ils ouvrent le fichier, écrivent, puis referment le fichier. Pas mal de logiciels passent par un fichier temporaire : ils ouvrent un fichier temporaire, écrivent dedans, le referme, puis déplace ensuite le fichier temporaire au-dessus de l'ancienne version.
Encore une fois, c'est l'idée générale. En vrai, c'est plus compliqué que ça. Je recommande la lecture de https://danluu.com/deconstruct-files/ pour ceux qui veulent creuser le sujet.
De l'autre côté des logiciels comme keypass peuvent limiter fortement les risques. En manipulant correctement leur fichier, ils presque n'y appliquer que des opérations automatiques.
Ils pourraient, mais, à ma connaissance, ce n'est pas comme ça qu'ils fonctionnent. Ils ont un mode de fonctionnement qui ressemble plutôt à une base de données, mais sans la même qualité d'implémentation. Le fichier est ouvert en permanence pendant que le logiciel tourne, souvent avec un second fichier qui sert de verrou (« lock-file »). Les écritures ne se font pas séquentiellement du début vers la fin, mais en sautant d'un endroit à un autre. Ils n'ont pas de journal d'écriture qui permet de repartir en cas de problème. Ils pourraient utiliser sqlite3 plutôt que le format de fichiers kdbx... mais ils ne le font pas.
Même avec tout ça, il faut qu'ily ait une copie incorrecte qui se passe sans avoir de copie correcte quelques secondes plus tard. C'est possible, mais ça réduit encore les risques.
J'avais creusé la question pour le client desktop de Cozy et j'étais tombé sur beaucoup de messages dans des forums de personnes qui avaient perdu leur base de mots de passe keepass à cause de ce genre de problème. Ce n'est pas qu'un problème théorique. Après, c'est aussi possible que ça reste très rare et que mon avis soit biaisé parce que j'ai justement creusé les forums pour aller chercher ce genre de problèmes.
[^] # Re: Intérêt du modèle client/serveur ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Bitwarden, un gestionnaire de mots de passe libre. Évalué à 2.
Je confirme, c'est l'idée. C'est bien entendu plus compliqué que ça (FsWatcher, l'équivalent de inotify pour macOS n'a pas d'événements pour les close par exemple), mais en gros, ça revient à écouter les changements sur une partie de l’arborescence, et quand un fichier change, on attend un peu après les derniers changements, puis on va lire progressivement le fichier et envoyer ça au serveur.
En général, la plupart des logiciels gardent les documents des utilisateurs ouverts (au sens avec un file handler) pendant des périodes de temps très courtes. Au moment où ils font la sauvegarde, ils ouvrent le fichier, écrivent, puis referment le fichier. Pas mal de logiciels passent par un fichier temporaire : ils ouvrent un fichier temporaire, écrivent dedans, le referme, puis déplace ensuite le fichier temporaire au-dessus de l'ancienne version.
Encore une fois, c'est l'idée générale. En vrai, c'est plus compliqué que ça. Je recommande la lecture de https://danluu.com/deconstruct-files/ pour ceux qui veulent creuser le sujet.
Ils pourraient, mais, à ma connaissance, ce n'est pas comme ça qu'ils fonctionnent. Ils ont un mode de fonctionnement qui ressemble plutôt à une base de données, mais sans la même qualité d'implémentation. Le fichier est ouvert en permanence pendant que le logiciel tourne, souvent avec un second fichier qui sert de verrou (« lock-file »). Les écritures ne se font pas séquentiellement du début vers la fin, mais en sautant d'un endroit à un autre. Ils n'ont pas de journal d'écriture qui permet de repartir en cas de problème. Ils pourraient utiliser sqlite3 plutôt que le format de fichiers kdbx... mais ils ne le font pas.
J'avais creusé la question pour le client desktop de Cozy et j'étais tombé sur beaucoup de messages dans des forums de personnes qui avaient perdu leur base de mots de passe keepass à cause de ce genre de problème. Ce n'est pas qu'un problème théorique. Après, c'est aussi possible que ça reste très rare et que mon avis soit biaisé parce que j'ai justement creusé les forums pour aller chercher ce genre de problèmes.