Google Drive come Git: DriveSync mostra le differenze prima di sincronizzare

Sincronizzare Google Drive da terminale senza affidarsi a un client grafico residente in memoria non è un’idea nuova, ma DriveSync (download) prova a renderla più prevedibile e controllabile. Il progetto di ScaleNinja è una CLI open source (licenza MIT) scritta in Rust per macOS, Linux e Windows che lavora su una cartella locale: mostra cosa cambierà, poi lascia scegliere se inviare i file verso il cloud con push oppure recuperarli con pull.

La filosofia ricorda strumenti storici come rsync e i precedenti client Google Drive da riga di comando, tanto che gli sviluppatori dichiarano esplicitamente di essersi ispirati al progetto odeke-em/drive. La differenza interessante sta soprattutto nelle protezioni introdotte attorno alla sincronizzazione e nell’uso delle API ufficiali di Google per evitare continue scansioni complete del contenuto remoto.

DriveSync trasforma Google Drive in una cartella controllabile da terminale

Il funzionamento ruota attorno a quattro comandi principali. dsync init associa una directory locale a una cartella remota; dsync diff confronta le due parti senza modificare nulla; dsync push trasferisce verso Drive le modifiche locali; dsync pull compie l’operazione inversa.

C’è anche dsync status, utile per controllare cartella associata, stato della cache, file di esclusione, filesystem e scadenza del token di autenticazione.

DriveSync costruisce un piano delle operazioni e lo mostra all’utente: nuovi file, modifiche, conflitti, elementi ignorati ed eventuali cancellazioni risultano visibili prima di procedere.

Una sincronizzazione non equivale automaticamente a dire “rendi le due cartelle identiche a qualunque costo“: un conflitto resta tale e non viene sovrascritto senza --force; una collisione dovuta alla differenza tra maiuscole, minuscole o normalizzazione Unicode può addirittura bloccare il trasferimento.

L’opzione -y, o --no-prompt, elimina la conferma interattiva, ma DriveSync rifiuta comunque di procedere in presenza di conflitti non risolti.

Come DriveSync scopre quali file sono cambiati

Una sincronizzazione efficiente non può rileggere e calcolare l’hash di migliaia di file a ogni esecuzione. DriveSync utilizza quindi un indice SQLite locale e memorizza gli hash dei file insieme a dimensione e data di ultima modifica, cioè il valore mtime.

Se al controllo successivo entrambi i valori risultano identici a quelli già registrati, il programma presume che il contenuto del file non sia cambiato e riutilizza l’hash determinato in precedenza. In questo modo non deve riaprire e rileggere integralmente il file dal disco, operazione che può diventare costosa quando si lavora con archivi molto grandi o migliaia di elementi.

Per i normali file binari presenti su Google Drive entra in gioco il campo MD5 checksum fornito dall’API. La documentazione di Google conferma che md5Checksum è disponibile per i file con contenuto memorizzato effettivamente in Drive, non per i documenti nativi degli editor Google.

DriveSync sfrutta quindi un confronto progressivo: una dimensione differente indica subito due contenuti diversi; se la dimensione coincide, confronta l’MD5 locale con quello remoto. Due hash uguali significano file identici indipendentemente dai timestamp; hash differenti portano invece a valutare la data di modifica, con una tolleranza di un secondo. Se i contenuti differiscono ma il timestamp coincide, il programma segnala un conflitto.

Due opzioni permettono di modificare il compromesso fra velocità e accuratezza. Con --fast, dimensione e data di modifica coincidenti bastano per considerare uguali i file, in maniera simile alla modalità rapida di rsync. --verify fa l’opposto: forza la rilettura dei file che richiedono un hash e ignora la cache locale. Quest’ultima modalità può essere utile dopo il ripristino di un backup o con programmi che modificano il contenuto preservando artificialmente gli stessi timestamp.

La Changes API evita di scansionare ogni volta tutto l’archivio Google Drive

Un altro elemento tecnico interessante riguarda il lato remoto. Alla prima indicizzazione DriveSync deve ricostruire l’albero interessato; successivamente sfrutta la Google Drive Changes API. Google espone attraverso changes.list la sequenza delle modifiche successive a un determinato page token e permette a un’applicazione di conservare un nuovo token da usare nelle interrogazioni successive.

Tradotto sul piano pratico, DriveSync non deve chiedere ogni volta l’elenco completo dei file per scoprire che ne è cambiato soltanto uno: mantiene la sua rappresentazione locale e recupera le variazioni intervenute nel frattempo. Per cartelle di grandi dimensioni, la differenza può diventare rilevante, soprattutto quando il comando viene eseguito spesso.

Resta disponibile --refresh, che ignora l’indice remoto e obbliga il programma a ricostruirlo. Va detto però che un full listing ha un costo: secondo gli stessi sviluppatori, durante l’operazione DriveSync mantiene in memoria tutti gli elementi presenti su Google Drive necessari alla costruzione dell’albero.

Trasferimenti paralleli e upload che possono essere recuperati

DriveSync utilizza 8 flussi paralleli per impostazione predefinita e permette di arrivare fino a 64 worker con l’opzione -j. Aumentare indiscriminatamente il numero dei thread non garantisce però un trasferimento più rapido: entrano in gioco banda disponibile, latenza, prestazioni del disco e limiti imposti dalle API.

Per i file superiori a 5 MB il programma utilizza gli upload resumable di Google Drive: una sessione di caricamento che può essere recuperata conserva un URI dedicato e, dopo un’interruzione, il client può interrogare Google per capire fino a quale byte il server ha ricevuto correttamente i dati. Non serve quindi ricominciare da zero dopo ogni errore di rete.

DriveSync conserva le informazioni della sessione nella directory locale .gd/ e può riprendere il caricamento anche dopo il riavvio del programma, purché dimensione e data di modifica del file non siano cambiate.

Fra le caratteristiche più interessanti del progetto c’è l’attenzione alle condizioni che possono cambiare tra la creazione del piano e il trasferimento vero e proprio. Un file locale potrebbe essere modificato da un altro programma pochi istanti dopo dsync diff; allo stesso modo, un collaboratore potrebbe aggiornare la copia su Google Drive mentre DriveSync si prepara al push. Per ridurre il rischio, il programma ricontrolla la destinazione immediatamente prima della scrittura.

Il parametro –delete merita particolare attenzione

Per impostazione predefinita DriveSync non cancella file. Se un elemento sparisce dalla sorgente, la copia rimasta sulla destinazione non viene rimossa automaticamente. Serve indicare esplicitamente --delete per ottenere un comportamento simile a rsync --delete.

Anche qui gli sviluppatori hanno aggiunto alcune protezioni. Le cancellazioni compaiono nel piano, sono eseguite dopo i trasferimenti e partono soltanto se tutte le copie previste hanno avuto successo. Una sorgente completamente vuota non può inoltre diventare accidentalmente equivalente all’indicazione di svuotare la destinazione: in quel caso DriveSync interrompe l’operazione.

Il risultato dipende però dal sistema operativo. Con push --delete gli oggetti remoti finiscono nel cestino di Google Drive. Durante un pull --delete, macOS sposta i file nel Cestino e Windows nel Cestino di sistema; su Linux la cancellazione locale è definitiva, perché DriveSync non integra al momento un meccanismo simile al Cestino degli altri sistemi operativi.

OAuth: DriveSync non porta con sé le credenziali di qualcun altro

DriveSync non contiene un client OAuth condiviso predisposto dal produttore: l’utente deve creare un progetto nella Google Cloud Console, abilitare la Drive API e generare proprie credenziali OAuth Desktop. Durante dsync init si apre il browser per il consenso e il codice di autorizzazione torna all’applicazione attraverso una porta loopback locale. Token e metadati finiscono nella directory .gd/, che DriveSync esclude dalla sincronizzazione.

Sui sistemi Unix i token vengono creati con permessi 0600; su Windows non esiste l’equivalente dei mode bit POSIX e la protezione dipende dalle ACL del profilo utente.

Se la cartella sincronizzata è anche un repository Git, gli autori consigliano di aggiungere .gd/ a .gitignore: è un accorgimento semplice, ma essenziale per non pubblicare accidentalmente materiale di autenticazione.

I documenti Google Documenti, Fogli e Presentazioni non sono veri file da sincronizzare

DriveSync lavora bene con PDF, immagini, archivi, sorgenti, documenti Office e in generale con oggetti che Google Drive conserva come contenuto binario. La situazione cambia con Google Documenti, Fogli e Presentazioni: nella rappresentazione di Drive non possiedono un normale blob da scaricare e non espongono il checksum MD5 usato dal programma.

Google mette a disposizione API specifiche per esportare i documenti Workspace verso formati come DOCX, XLSX, PDF o altri MIME type supportati.

DriveSync, però, non effettua tale conversione: elenca gli oggetti nativi Google quando li incontra, ma li salta e non prova né a scaricarli né a sovrascriverli. È quindi improprio pensare alla cartella locale come a una replica completa dell’intero account Google Drive.

Se il proprio archivio contenesse molti documenti creati direttamente con gli editor Google, la limitazione della quale abbiamo parlato risulta rilevante.

Perché DriveSync è interessante anche se ancora acerbo

DriveSync non prova a competere sul numero di provider supportati. A differenza di rclone, si concentra su un solo servizio, una cartella locale e una cartella Google Drive.

Proprio questa scelta gli consente di proporre un modello relativamente facile da comprendere: vedere prima il piano, rilevare i conflitti, trasferire in parallelo, verificare gli hash e richiedere opzioni esplicite per le operazioni distruttive.

Per amministratori, sviluppatori e utenti che preferiscono script riproducibili al client grafico, l’idea ha senso (qui le indicazioni per l’installazione). Una CLI può essere inserita in script shell, procedure di backup selettive o attività schedulate e dsync diff, restituendo uno stato differente quando trova variazioni, si presta anche a controlli automatizzati.

DriveSync può propagare modifiche e, usando --delete, anche cancellazioni; non conserva una cronologia locale delle versioni e un pull che sovrascrive un file locale più vecchio non crea automaticamente una copia di sicurezza. Google Drive mantiene proprie revisioni per determinati file, ma si tratta di una caratteristica del servizio remoto, non di una politica di backup gestita dalla CLI.

La base tecnica è comunque interessante, soprattutto per un progetto molto recente: cache SQLite, Changes API, controlli MD5, sessioni recuperabili, trasferimenti paralleli e verifiche prima della scrittura mostrano attenzione ai problemi reali della sincronizzazione. Il vero banco di prova sarà la maturazione del codice, in particolare su Linux e Windows, insieme alla gestione dei casi limite che emergono soltanto dopo l’uso quotidiano su archivi molto grandi.

Per ora DriveSync è uno strumento da osservare e, per chi sa bene cosa sta sincronizzando, anche da sperimentare.