Sono un fan dichiarato della sovranità dei dati, e per questo gestisco un mio NAS Synology. Nella maggior parte dei casi funziona benissimo, ma ogni tanto qualche piccolo problema non manca. Lavorando con Synology Drive Client su Windows mi capita regolarmente di incontrare problemi di sincronizzazione, il cui debug non è del tutto semplice: in particolare la vista dei log nell’interfaccia del client è piuttosto scomoda. Dopo un po’ di tentativi ho trovato un metodo che funziona bene.
Di recente avevo il problema che alcuni file non venivano sincronizzati perché il percorso era troppo lungo per Windows. Quindi non è colpa di Synology, ma di Windows. Volevo correggere questi file, ma con alcune centinaia di file è utile poter procedere in modo strutturato e conoscere con precisione i file coinvolti.
Perché i log standard non aiutano
Synology Drive Client per Windows (nel mio caso la versione 4.0.1) mostra i problemi di sincronizzazione nell’interfaccia, ma:
- La vista dei log integrata si può a malapena consultare in modo utile
- I classici file di log (ad es. daemon.log) nella cartella AppData non sembrano contenere gli errori mostrati nell’interfaccia
- Nei log di testo si trovano informazioni a livello di file, ma nei miei test i file problematici non erano reperibili lì (probabilmente un altro tipo di log)
Cosa funziona davvero: il database SQLite
Dopo un po’ di ricerca ho scoperto che Synology Drive Client salva le informazioni di sincronizzazione in database SQLite. Nel mio caso si trovano qui:
C:\Users\[Benutzername]\AppData\Local\SynologyDrive\data\db\Il file rilevante: history.sqlite
Procedura pratica
1. Chiudere il Drive Client
Importante: chiudere completamente il client dall’icona nella barra delle applicazioni (clic destro → Esci). In questo modo tutti i dati vengono scritti dal file WAL temporaneo di SQLite (Write-Ahead Log) nel database principale.
2. Procurarsi uno strumento SQLite
Io uso DB Browser for SQLite.
3. Aprire il database
- Aprire history.sqlite in DB Browser (consiglio: per sicurezza lavorare su una copia, non sull’originale)
- Richiamare la scheda “Browse Data”
- Selezionare la tabella history_table
4. Identificare i problemi
Colonne rilevanti nel database:
- path – percorso del file
- is_not_synced – stato di sincronizzazione
- not_synced_reason – codice di errore
Trucco per il filtro: fare clic sull’intestazione della colonna is_not_synced e filtrare per = 1 – in questo modo vengono mostrati solo i file non sincronizzati.
Interpretare i codici di errore
La colonna not_synced_reason contiene valori negativi. Quello che ho scoperto finora:
- -4096: sembra comparire spesso in caso di percorsi troppo lunghi (limite MAX_PATH di Windows di 260 caratteri)
- Altri valori: non documentati ufficialmente, ma di solito si possono interpretare confrontandoli con il messaggio di errore nell’interfaccia
Osservazione: anche file con percorsi brevi possono avere -4096 (ad es. desktop.ini con sole 67 caratteri). Il significato esatto dei codici non mi è noto – se qualcuno conosce una documentazione ufficiale, mi faccia pure sapere.
Conclusione
Questo approccio tramite il database SQLite mi ha aiutato molto più dei log di testo. I dati sono strutturati, filtrabili e contengono esattamente le informazioni mostrate anche nell’interfaccia – solo che qui sono consultabili.
Basato sull’esperienza con Synology Drive Client 4.0.1 su Windows