Je suis un fan déclaré de la souveraineté des données et j’exploite donc mon propre NAS Synology. Cela fonctionne très bien dans l’ensemble, mais il y a toujours un petit problème qui surgit de temps en temps. En travaillant avec Synology Drive Client sous Windows, je rencontre régulièrement des problèmes de synchronisation dont le débogage n’est pas évident, d’autant que la vue des logs dans l’interface du client est plutôt bancale. Après quelques essais, j’ai trouvé une méthode qui fonctionne bien.
Récemment, j’avais le problème que certains fichiers n’étaient pas synchronisés parce que le chemin était trop long pour Windows. Ce n’est donc pas la faute de Synology, mais de Windows. Je voulais corriger ces fichiers, mais avec plusieurs centaines de fichiers, il est utile de procéder de manière structurée et de connaître précisément les fichiers concernés.
Pourquoi les logs standard n’aident pas
Le client Synology Drive pour Windows (chez moi en version 4.0.1) affiche bien les problèmes de synchro dans l’interface, mais :
- La vue des journaux intégrée ne permet guère de recherche utile
- Les fichiers de logs classiques (par ex. daemon.log) dans le répertoire AppData ne semblent pas contenir les erreurs affichées dans l’interface
- Les logs texte contiennent certes des informations au niveau des fichiers, mais lors de mes tests, les fichiers problématiques n’y étaient pas repérables (probablement un autre type de log)
Ce qui fonctionne réellement : la base de données SQLite
Après quelques recherches, j’ai découvert que Synology Drive Client stocke les informations de synchro dans des bases de données SQLite. Chez moi, elles se trouvent sous :
C:\Users\[Benutzername]\AppData\Local\SynologyDrive\data\db\Le fichier pertinent : history.sqlite
Démarche pratique
1. Fermer le client Drive
Important : fermer complètement le client via l’icône dans la barre des tâches (clic droit → Quitter). Cela permet d’écrire toutes les données du fichier temporaire SQLite WAL (Write-Ahead Log) dans la base de données principale.
2. Se procurer un outil SQLite
J’utilise DB Browser for SQLite.
3. Ouvrir la base de données
- Ouvrir history.sqlite dans DB Browser (astuce : par précaution, travailler sur une copie, pas sur l’original)
- Ouvrir l’onglet « Parcourir les données » (Browse Data)
- Sélectionner la table history_table
4. Identifier les problèmes
Colonnes pertinentes dans la base de données :
- path – chemin du fichier
- is_not_synced – statut de synchro
- not_synced_reason – code d’erreur
Astuce de filtrage : cliquer sur l’en-tête de colonne is_not_synced et filtrer sur = 1 – seuls les fichiers non synchronisés s’affichent alors.
Interpréter les codes d’erreur
La colonne not_synced_reason contient des valeurs négatives. Voici ce que j’ai découvert jusqu’à présent :
- -4096 : semble apparaître fréquemment avec des chemins trop longs (limite Windows MAX_PATH de 260 caractères)
- Autres valeurs : non documentées officiellement, mais généralement interprétables en les comparant au message d’erreur affiché dans l’interface
Observation : même des fichiers avec des chemins courts peuvent avoir -4096 (par ex. desktop.ini avec seulement 67 caractères). Je ne connais pas la signification exacte de ces codes – si quelqu’un connaît une documentation officielle, qu’il n’hésite pas à me le signaler.
Mon bilan
Cette approche via la base de données SQLite m’a bien plus aidé que les logs texte. Les données sont structurées, filtrables et contiennent exactement les informations affichées dans l’interface – mais avec la possibilité de les rechercher.
Basé sur l’expérience avec Synology Drive Client 4.0.1 sous Windows