Syncthing 2.0, l'application open source de synchronisation de fichiers peer-to-peer, est disponible
Syncthing 2.0, l'application open source de synchronisation de fichiers, est disponible, avec une migration SQLite, de nouvelles capacités de journalisation, des changements de plateforme et plus encore
Syncthing 2.0 est arrivé, marquant une version majeure pour la populaire solution open source de synchronisation continue de fichiers. La nouvelle version migre sa base de données de LevelDB à SQLite pour améliorer la maintenance et la fiabilité, introduit des journaux structurés avec des contrôles granulaires, supprime les binaires préconstruits sur plusieurs plateformes mineures en raison de l'exigence de SQLite, et apporte des changements ayant un impact sur le flux de travail.
Syncthing est une application de synchronisation de fichiers peer-to-peer gratuite et open source disponible pour Windows, macOS, Linux, Android, Solaris, Darwin et BSD. Elle peut synchroniser des fichiers entre des appareils sur un réseau local ou entre des appareils distants sur Internet. La sécurité des données est intégrée dans sa conception. La version 1.0 a été publiée en janvier 2019 après cinq ans en version bêta.
Avec cette mise à jour, le backend de la base de données passe de LevelDB à SQLite, afin de faciliter la maintenance et d'améliorer la fiabilité. Les utilisateurs bénéficient également de capacités de diagnostic améliorées, car la journalisation utilise désormais des entrées structurées avec des contrôles de niveau de journalisation par paquet nouvellement introduits et un nouveau niveau WARNING positionné entre INFO et ERROR.
Pour les utilisateurs de systèmes moins courants, des changements notables ont été apportés à la distribution. Les binaires préconstruits ne sont plus fournis pour DragonFlyBSD (AMD64), Illumos (AMD64), Linux on PowerPC64, NetBSD, OpenBSD (386, ARM), et Windows on ARM à cause de la nouvelle dépendance SQLite. Les utilisateurs de ces plateformes doivent maintenant compiler Syncthing à partir des sources. Suite à ces changements fondamentaux, plusieurs ajustements de comportement affecteront les flux de travail : les éléments supprimés dans la base de données sont désormais oubliés après six mois au lieu d'être conservés indéfiniment, et le « dossier par défaut » n'est plus créé lors du premier démarrage, ce qui nécessite une configuration manuelle.
L'analyse des options de la ligne de commande a été modernisée, avec la suppression des options longues à tiret unique, plusieurs options ont été renommées et la prise en charge des variables d'environnement a été étendue.
Parmi les autres mises à jour techniques, on peut citer la suppression de la détection des hachages roulants pour les données décalées, ce qui permet des analyses plus rapides, l'adoption de trois connexions par défaut entre les périphériques v2 et l'amélioration de la résolution des conflits de fichiers, qui peut désormais se traduire par des copies de conflits déplacées lorsque les suppressions l'emportent.
Les changements majeurs apportés par cette version sont les suivants :
- La base de données est passée de LevelDB à SQLite. Il y a une migration lors du premier lancement qui peut être longue pour les grandes installations. La nouvelle base de données est plus facile à comprendre et à maintenir et, espérons-le, moins boguée.
- Le format de journalisation a été modifié pour utiliser des entrées de journal structurées (un message plus plusieurs paires clé-valeur). De plus, les utilisateurs peuvent désormais contrôler le niveau de journalisation par paquet, et un nouveau niveau de journalisation WARNING a été inséré entre INFO et ERROR (qui était auparavant connu sous le nom de WARNING...). Le niveau INFO est devenu plus verbeux, indiquant les actions de synchronisation prises par Syncthing. Un nouvel indicateur de ligne de commande --log-level définit le niveau de journalisation par défaut pour tous les paquets, et la variable d'environnement STTRACE ainsi que l'interface graphique ont été mises à jour pour définir les niveaux de journalisation par paquet. Les options de ligne de commande --verbose et --logflags ont été supprimées et seront ignorées si elles sont données.
- Les éléments supprimés ne sont plus conservés pour toujours dans la base de données, mais sont oubliés au bout de quinze mois. Si le cas d'utilisation d'un utilisateur exige que les suppressions prennent effet après un délai supérieur à quinze mois, il peut définir l'option de ligne de commande --db-delete-retention-interval ou la variable d'environnement correspondante à zéro, ou à un intervalle de temps plus long de son choix.
- Modernisation de l'analyse des options de la ligne de commande. Les anciennes options longues avec un seul tiret ne sont plus supportées, par exemple -home doit être donné comme --home. Certaines options ont été renommées, d'autres sont devenues des sous-commandes. Toutes les options serve sont maintenant acceptées comme variables d'environnement. Voir syncthing --help et syncthing serve --help pour plus de détails.
- La détection des hachages roulants des données décalées n'est plus prise en charge, car « elle n'a jamais été d'une grande utilité », selon l'éditeur. Au lieu de cela, l'analyse et la synchronisation sont plus rapides et plus efficaces sans cette détection.
- Un "dossier par défaut" n'est plus créé au premier démarrage.
- Les connexions multiples sont désormais utilisées par défaut entre les appareils v2. La nouvelle valeur par défaut est d'utiliser trois connexions : une pour les métadonnées d'index et deux pour l'échange de données.
- Les plateformes suivantes n'ont malheureusement plus de binaires préconstruits à télécharger sur syncthing.net et sur GitHub, en raison de complexités liées à la compilation croisée avec SQLite :
- dragonfly/amd64
- illumos/amd64 et solaris/amd64
- linux/ppc64
- netbsd/*
- openbsd/386 et openbsd/arm
- windows/arm
- La gestion de la résolution des conflits impliquant des fichiers supprimés a été modifiée. Une suppression peut désormais être le résultat gagnant de la résolution de conflit, ce qui entraîne le déplacement du fichier supprimé vers une copie de conflit.
Source : Syncthing 2.0
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Répondre avec citation
Envoyé par marc.collin
Partager