Annexe B : historique et architecture¶
ownCloud propose des clients de synchronisation pour synchroniser les contenus des dossiers locaux des ordinateurs, des tablettes ou des mobiles vers le serveur ownCloud.
La synchronisation est réalisée en utilisant csync, un outil de synchronisation de fichiers bi-directionnelle qui fournit un client en ligne de commande et une bibliothèque. Un module spécial pour csync a été écrit pour la synchronisation avec le serveur WebDAV intégré d’ownCloud.
Le logiciel client d’ownCloud est écrit en C++ en utilisant le Framework Qt. Ceci permet au client ownCloud de fonctionner sous Linux, Windows et Mac OS.
Le processus de synchronisation¶
Le processus de synchronisation conserve les fichiers à l’identique dans deux dépôts distincts. Lors de la synchronisation :
- si un fichier est ajouté à un dépôt, il est copié dans tout autre dépôt synchronisé ;
- quand un fichier est modifié dans un dépôt, la modification est propagée dans tout autre dépôt synchronisé ;
- si un fichier est supprimé, il est supprimé dans tout autre dépôt synchronisé.
Il est important de noter que le processus de synchronisation d’ownCloud n’utilise pas un système client-serveur typique où le serveur est toujours le maître. C’est une différence majeure entre le processus de synchronisation d’ownCloud et les autres systèmes, comme la sauvegarde de fichiers, où seuls les fichiers ou dossiers modifiés et l’ajout de nouveaux fichiers sont propagés, mais les fichiers ou dossiers ne sont jamais supprimés à moins de l’être explicitement dans la sauvegarde elle-même.
Pendant la synchronisation, le client ownCloud vérifie fréquemment les changements dans les deux dépôts. Ce processus est appelé sync run. Entre deux « sync run », le dépôt local est scruté par un processus de scrutation de système de fichiers qui lance un « sync run » immédiatement si quelque chose est édité, ajouté ou supprimé.
Synchronisation par horodatage et par ETag¶
Jusqu’à la version 4.5 du serveur ownCloud et 1.1 du client ownCloud, le processus de synchronisation d’ownCloud utilisait une seule propriété de fichier —l’heure de modification du fichier— pour décider si un fichier était plus récent et avait besoin d’être synchronisé dans l’autre dépôt.
L’horodatage de modification fait partie des méta-données de fichiers. Il est disponible dans chaque système de fichiers et est l’indicateur typique d’une modification du fichier. Les horodatages de modification ne nécessitent pas d’action spéciale pour être créés et ont une signification générale. Un des buts dans la conception de csync est de ne pas avoir un composant serveur spécial. C’est pourquoi csync a été choisi comme service de synchronisation.
Pour comparer les heures de modification de deux fichiers sur des systèmes différents, csync doit opérer sur la même base. Avant la version 1.1.0 du client ownCloud, csync nécessitait que les systèmes hébergeant les deux dépôts soient calés sur la même heure. Ceci était obtenu par l’utilisation du standard d’entreprise heure de synchronisation NTP sur toutes les machines.
En raison de la fragilité de cette stratégie d’horodatage sans l’utilisation de NTP, ownCloud 4.5 a introduit un nombre unique (pour chaque fichier) qui change à chaque modification du fichier. Bien que ce nombre soit unique, il ne s’agit pas d’un « hash » du fichier, mais d’un nombre choisi aléatoirement, transmis dans le champ Etag. Parce que ce nombre change si le fichier est modifié, son utilisation permet de déterminer si le fichier a été modifié et démarre le processus de synchronisation.
Note
La version 1.1 du client ownCloud et ses versions suivantes nécessitent l’aptitude à gérer les identifiants de fichiers sur le serveur ownCloud. Les serveurs utilisant des versions antérieures à la version 4.5.0 ne gèrent pas l’utilisation de la fonctionnalité d’identifiant de fichier.
Avant la version 1.3.0 du client pour ordinateur, le processus de synchronisation pouvait créer de faux conflits de fichiers si l’heure variait. Les fichiers originaux et modifiés n’étaient en conflit que sur leur horodatage mais pas sur leur contenu. Ce comportement a été modifié en utilisation une vérification binaire des fichiers en cas de conflit.
Comme les fichiers, les répertoires ont aussi un identifiant unique qui change chaque fois qu’un de ses fichiers ou de ses sous-répertoires est modifié. Comme il s’agit d’un processus récursif, cela réduit considérablement les ressources utilisées pour un cycle de synchronisation car le client n’analyse que les répertoires dont l’identifiant a été modifié.
Le tableau suivant indique les méthodes de synchronisation utilisées en fonction de la combinaison serveur-client :
| Version serveur | Version client | Méthodes de synchronisation |
|---|---|---|
| 4.0.x ou précédents | 1.0.5 ou précédents | Horodatage |
| 4.0.x ou précédents | 1.1 ou suivants | n/a (incompatible) |
| 4.5 ou suivants | 1.0.5 ou précédents | Horodatage |
| 4.5 ou suivants | 1.1 ou suivants | Identifiant, horodatage |
Nous recommandons vivement d’utiliser les versions 4.5 ou suivantes du serveur ownCloud lors de l’utilisation des versions 1.1 ou suivantes du client ownCloud. L’utilisation d’un mécanisme de synchronisation incompatible basé sur l’horodatage peut conduire à des pertes de données, particulièrement quand plusieurs clients sont utilisés et que l’un d’entre eux n’est pas calé sur l’heure NTP.
Comparaison et cas de conflits¶
Comme mentionné ci-dessus, pendant un sync run, le client doit d’abord détecter si l’un des deux dépôts contient des fichiers modifiés. Sur le dépôt local, le client parcourt l’arborescence de fichiers, et compare l’horodatage de chaque fichier avec la valeur attendue stockée dans sa base de données. Si la valeur n’est pas la même, le client détermine que le fichier a été modifié dans le dépôt local.
Note
Sur le dépôt local, l’horodatage est un bon attribut à utiliser pour la détection des modifications car la valeur ne dépend pas du fuseau horaire ou autre.
Pour le dépôt distant (c’est-à-dire sur le serveur ownCloud), le client compare le ETag de chaque fichier avec sa valeur attendue. À nouveau, la valeur de l’ETag est recherchée dans la base de données du client. Si l’ETag est le même, le fichier n’a pas été modifié et aucune synchronisation ne survient.
Dans l’hypothèse où un fichier a été modifié à la fois sur le dépôt local et le dépôt distant depuis la dernière synchronisation, il est difficle de déterminer quelle version du fichier doit être utilisée. Cependant, les modifications survenues de part et d’autre ne seront pas perdues. Un cas de conflit est alors créé. Le client résout le conflit en créant un fichier de conflit du plus vieux des deux fichiers et sauvegarde le plus récent avec le nom original du fichier. Les fichiers de conflit sont toujours crééssur le client et jamais sur le serveur. Le fichier de conflit utilise le nom du fichier original auquel est ajouté l’horodatage de la détection du conflit.
Fichiers ignorés¶
Le client ownCloud offre la possibilité d’exclure ou d’ignorer certains fichiers dans le processus de synchronisation. Certains motifs pour exclure les fichiers sont inclus par défaut dans le client et des motifs personnalisés peuvent être ajoutés.
Par défaut, le client ownCloud ignore les fichiers suivants :
- les fichiers correspondant aux motifs définis dans l’éditeur de fichiers ignorés ;
- les fichiers contenant des caractères qui ne fonctionnent pas sur certains systèmes de fichiers (`\, /, :, ?, *, ", >, <, |`) ;
- les fichiers commençant par .csync_journal.db, car ces fichiers sont réservés pour la jounalisation.
Si un motif est sélecttionné en cochant la case ignoredFilesEditor-label (ou si une ligne dans le fichier d’exclusion commence par ] directement suivi par le motif de fichier),les fichiers correspondant au motif sont considèrés comme des méta-données volatiles. Ces fichiers sont ignorés et supprimés par le client s’ils sont trouvés dans le répertoire synchronisé. Ceci est adapté pour les fichiers créés par certaines applications et qui n’ont pas de signification durable.
Si un fichier se termine par une barre de fraction (/), seuls les répertoires sont comparés. Le motif est seulement utilisé pour les noms de répertoires sélectionnés en utilisant la case à cocher.
Pour la correspondance des noms de fichiers avec les motifs, la fonction de la bibliothèque C standard « fnmatch » est utilisée. Ce processus vérifie le nom du fichier en fonction du motif en utilisant les méta-caractères standards du shell. Pour plus d’informations, veuillez consulter le site Web de l’Opengroup.
Le chemin vérifié est le chemin relatif à partir de la racine du répertoire synchronisé.
Exemples de motifs et de correspondance de fichiers :
| Motif | Correspondance de fichiers |
|---|---|
| ~$* | ~$foo, ~$exemple.doc |
| fl?p | flip, flap |
| moo/ | map/moo/, moo/ |
Le journal de synchronisation¶
Le client stocke le nombre ETag dans une base de données par répertoire, appelée journal. Cette base de données est un fichier caché contenu dans le répertoire synchronisé.
Si la base de données journal est supprimée, le service CSync du client de synchronisation ownCloud reconstruit la base de données en comparant les fichiers et leur horodatage de modification. Ce processus assure que le serveur et le client sont synchronisés en utilisant l’heure NTP appropriée avant de redémarrer le client après une suppression de base de données.
Appuyer sur a touche F5 tout en étant dans le dialogue de paramètres de compte permet de « réinitialiser » le journal. Cette fonction peut être utilisée pour recréer la base de données journal.
Note
Nous vous recommandons d’effectuer cette opération seulement quand vous y êtes invité par le personnel de support d’ownCloud.
Propriétés personnalisées WebDAV¶
Dans la communication entre le client et le serveur, des propriétés personnalisées WebDAV ont été introduites. Elles sont nécessaires pour la fonctionnalité de synchronisation et pour l’amélioration des performances de synchronisation.
Ce chapitre décrit les éléments XML additionnels que renvoie le serveur en réponse à une requête PROPFIND réussie sur un fichier ou un répertoire. Ces éléments sont renvoyés dns l’espace de nom oc.
Permissions côté serveur¶
L’élément XML <oc:permissions> représente la permission —et l’état de partage de l’élément. C’est une liste de caractères dont la signification est indiquée dans le tableau ci-dessous :
| Code | Ressource | Description |
| S | Fichier ou dossier | est partagé |
| R | Fichier ou dossier | peut partager (y compris le repartage) |
| M | Fichier ou dossier | est monté (comme pour DropBox, Samba, etc.) |
| W | Fichier | peut écrire un fichier |
| C | Dossier | peut créer un fichier dans le dossier |
| K | Dossier | peut créer un dossier (mkdir) |
| D | Fichier ou dossier | peut supprimer un fichier ou un dossier |
| N | Fichier ou dossier | peut renommer un fichier ou un dossier |
| V | Fichier ou dossier | peut déplacer un fichier ou un dossier |
Exemple :
<oc:permissions>RDNVCK</oc:permissions>
Taille de fichier ou de répertoire¶
L’élément XML <oc:size> représente la taille du fichier ou du répertoire en octets. Pour les répertoires, la taille comprend celle des sous-répertoires également.
Exemple :
<oc:size>2429176697</oc:size>
Identifiant de fichier¶
L’élément XML <oc:id> représente l’identifiant du fichier. C’est une chaîne non volatile qui reste constante tant que le fichier existe. Elle n’est pas changée si le fichier est modifié, renommé ou supprimé.
Exemple :
<oc:id>00000020oc5cfy6qqizm</oc:id>
