Présentation

DriveSync est un utilitaire en ligne de commande écrit en Rust qui maintient la cohérence entre un répertoire local et un dossier Google Drive. Il propose trois actions principales : dsync diff pour afficher les différences, dsync push pour envoyer les modifications locales, et dsync pull pour récupérer les changements distants. Le programme s’installe via Homebrew, un binaire précompilé (Linux x86_64, Linux arm64, macOS x86_64, macOS arm64) ou à partir du code source avec make install.

dsync init ~/gdrive --remote-folder backups/lab \
    --credentials ~/Downloads/client_secret.json

Architecture et mécanisme de synchronisation

Chaque côté de la synchronisation est représenté par une collection de chemins associés à trois métadonnées : taille, horodatage (mtime) et hash MD5. Google Drive calcule les MD5 côté serveur et les renvoie dans les listings, ce qui évite tout calcul local. L’algorithme compare d’abord les tailles ; si elles diffèrent, le fichier est marqué comme distinct sans lecture supplémentaire. En cas d’égalité, le hash MD5 local est comparé à celui fourni par Drive ; le cache MD5, indexé par taille et mtime, garantit qu’un fichier n’est haché qu’une fois, sauf si l’option --verify force un nouveau calcul.

Le plan de transfert repose sur une indexation complète du répertoire distant lors du premier lancement, puis sur le Drive Changes API pour maintenir l’index à jour. Cette approche réduit le nombre d’appels API aux itérations suivantes, car la liste complète n’est plus requise.

Gestion des conflits et fiabilité

DriveSync applique une résolution de conflit simple : le côté le plus récent (tolérance d’une seconde) l’emporte, sauf si les horodatages sont identiques mais les contenus différents, auquel cas le fichier est signalé comme conflit (C). Les conflits ne sont jamais résolus automatiquement ; l’utilisateur doit confirmer ou utiliser --force. Les fichiers Google Docs, Sheets ou Slides sont exclus du transfert car ils n’ont pas de représentation binaire.

Les transferts de fichiers supérieurs à 5 Mo utilisent les uploads résumables de Drive. En cas d’erreur réseau ou de dépassement de quota, le client effectue des tentatives avec back‑off exponentiel. Un upload interrompu reprend depuis le dernier octet reçu, grâce à un fichier de session stocké dans .gd/. Avant chaque écriture, DriveSync vérifie que la taille, le mtime et le MD5 du fichier correspondent toujours à l’état observé lors de la planification, ce qui empêche les écritures basées sur des données obsolètes.

Déploiement et exigences

L’authentification repose sur OAuth 2.0 : l’utilisateur crée un projet Google Cloud, active l’API Drive, génère un client ID de type « Desktop app » et télécharge le fichier JSON de credentials. Lors de la première initialisation, le navigateur ouvre la page de consentement, le code d’autorisation est récupéré sur un port de boucle locale, puis les tokens sont stockés dans .gd/ avec des permissions 0600. Les tokens de rafraîchissement expirent après 7 jours pour les applications en phase de test ; publier l’application dans la console supprime cette limitation.

DriveSync ne supporte pas la coordination entre plusieurs machines ; chaque instance travaille de façon indépendante, sans fusion à trois voies. Si le dossier distant est déplacé ou supprimé, toutes les commandes s’arrêtent avec un message explicite. Le cache SQLite .gd/cache.db est reconstruit automatiquement en cas de corruption, garantissant la continuité du service.