Comparatif de Conception

Cette page explique le positionnement architectural de Sync-in face à plusieurs plateformes open source de partage et synchronisation de fichiers. L'objectif n'est pas de classer les produits fonctionnalité par fonctionnalité, mais de clarifier les choix de stockage et de métadonnées importants pour l'exploitation, les migrations, les sauvegardes et le contrôle durable des données.

Positionnement de Sync-in

Sync-in conserve les fichiers dans leur système de fichiers d'origine. La plateforme ne transforme pas l'espace de stockage en dépôt applicatif opaque et ne nécessite pas une organisation spécifique de type stockage objet pour les fichiers ordinaires.

Les métadonnées collaboratives sont créées uniquement lorsqu'une fonctionnalité en a besoin : partage, permissions, ancrage virtuel, synchronisation, commentaires, activité, collaboration et état applicatif associé. La base de données reflète donc l'usage collaboratif de la plateforme plutôt qu'une duplication complète de l'arborescence par défaut.

Lorsqu'un fichier déjà porteur de métadonnées change sur le système de fichiers, Sync-in peut réconcilier l'état réel du stockage avec les métadonnées existantes. La plateforme conserve ainsi la cohérence de ses fonctions collaboratives sans transformer tous les fichiers en entrées obligatoires d'un cache global.

L'indexation plein texte est séparée de ce modèle de métadonnées. Elle concerne le contenu des documents, peut être activée ou désactivée, et peut s'appuyer sur des moteurs spécialisés pour la recherche plein texte, comme Elasticsearch, au lieu d'alourdir la base de données.

Cette approche apporte six bénéfices concrets :

• Stockage lisible : les fichiers restent directement exploitables par les outils standards du système.
• Simplicité d'exploitation : sauvegardes, snapshots, antivirus et traitements externes peuvent continuer à travailler sur des fichiers normaux.
• Surcharge d'indexation réduite : une grande arborescence n'implique pas automatiquement une grande base de métadonnées de fichiers.
• Scalabilité plus prévisible : la charge de la base de données suit d'abord l'usage fonctionnel, pas seulement le nombre brut de fichiers stockés.
• Réconciliation ciblée : les métadonnées existantes sont alignées avec l'état réel du système de fichiers lorsque c'est nécessaire.
• Réversibilité : une instance peut être arrêtée ou migrée sans devoir reconstruire les fichiers utilisateur depuis un format propriétaire.

Différences avec les architectures EFSS existantes

Nextcloud et ownCloud 10

Nextcloud et ownCloud 10 maintiennent un cache fichier qui reflète l'état des fichiers en base de données. Nextcloud documente des commandes comme files:scan, files:cleanup et files:repair-tree pour mettre à jour ou réparer ce cache, notamment après une copie directe dans le répertoire de données ou après une migration. La documentation de migration ownCloud décrit oc_filecache comme une table stockant les métadonnées fichier, dont une réplication complète de l'arborescence.

Ce modèle est puissant pour un large écosystème applicatif, mais il fait aussi de la base de données un composant opérationnel central pour la visibilité et la cohérence des fichiers.

Sources :

• Commandes fichier Nextcloud
• Détection des changements sur stockage externe Nextcloud
• Notes ownCloud sur oc_filecache

OpenCloud et ownCloud Infinite Scale

OpenCloud et ownCloud Infinite Scale s'éloignent de l'ancien modèle serveur PHP, mais restent fondés sur des pilotes de stockage avec un comportement spécifique pour les métadonnées. OpenCloud PosixFS stocke des métadonnées additionnelles dans les attributs étendus des fichiers et peut déplacer les métadonnées plus volumineuses dans un fichier séparé. ownCloud Infinite Scale PosixFS requiert aussi les attributs étendus et des notifications du système de fichiers pour l'accès partagé au stockage.

Ces architectures améliorent certains scénarios d'accès direct au système de fichiers, mais elles imposent toujours des exigences structurelles au système de fichiers sous-jacent et à ses capacités de métadonnées. Leur portabilité dépend donc de la conservation de ces métadonnées et des exigences du système de fichiers lors d'une copie, d'une restauration ou d'une migration vers une autre instance.

Sources :

• OpenCloud PosixFS
• ownCloud Infinite Scale PosixFS

Seafile

Seafile utilise un modèle interne inspiré de Git, avec des bibliothèques, commits, objets de système de fichiers et blocs de contenu. Les fichiers peuvent être découpés en blocs pour la déduplication et l'efficacité des transferts. Cette conception est solide pour la synchronisation et l'historique, mais le stockage n'est plus une arborescence de fichiers directement lisible telle que l'utilisateur la voit.

Sync-in fait un autre compromis opérationnel : il privilégie la lisibilité du système de fichiers et les métadonnées ciblées plutôt qu'un modèle d'objets spécialisé pour chaque fichier.

Source :

• Modèle de données Seafile

Syncthing

Syncthing est avant tout un système de synchronisation pair à pair, pas une plateforme EFSS centralisée de gouvernance documentaire. Il conserve les fichiers sur les appareils participants et suit les versions, listes de blocs et états de synchronisation dans une base d'index locale. Il s'appuie aussi sur des watchers du système de fichiers et des scans périodiques pour détecter les changements.

Cela rend Syncthing excellent pour la synchronisation décentralisée, mais son modèle n'apporte pas la même gouvernance serveur que Sync-in : espaces gérés, partage imbriqué, permissions déléguées, accès WebDAV, audit et administration centralisée.

Source :

• Modèle de synchronisation Syncthing

Ce qui différencie Sync-in

La différenciation de Sync-in ne tient pas seulement au fait que les fichiers sont stockés sur disque. Le point le plus précis est que Sync-in garde le système de fichiers comme réalité primaire du stockage, crée des métadonnées applicatives uniquement là où la collaboration les rend nécessaires, et sait réconcilier ces métadonnées avec l'état réel du stockage.

Cela donne un modèle EFSS pragmatique :

• Pas de dépôt opaque pour les fichiers ordinaires : les données restent lisibles hors de l'application.
• Pas de miroir complet de l'arborescence par défaut : la croissance de la base suit l'usage fonctionnel plutôt que le volume brut de fichiers.
• Scalabilité orientée usage : la plateforme peut héberger de très grandes arborescences sans convertir chaque fichier en état applicatif persistant.
• Réconciliation des états : les fichiers déjà associés à des métadonnées peuvent être réalignés avec le système de fichiers sans scanner toute l'arborescence comme source permanente de vérité applicative.
• Pas d'organisation imposée par un backend : le stockage peut rester proche des pratiques système existantes.
• Collaboration sans duplication : l'ancrage virtuel expose des contenus dans les espaces sans les copier.
• Gouvernance claire : managers, partages, permissions et activités restent gérés par la plateforme sans absorber le stockage lui-même.

Pour les administrateurs, le résultat est un modèle d'exploitation plus léger : moins de rescans globaux liés à la cohérence d'un cache complet de fichiers, moins de pression sur la base de données pour les très grandes arborescences, des sauvegardes et restaurations plus simples, et un couplage plus faible entre l'application et l'organisation physique du stockage.