Google Drive’s folder sync is one part of the client that’s supposed to just work, so I’ve stuck with it for years. But the experience hasn’t always been what I hoped for. I’ve experienced the drive’s sync icon spinning next to files I haven’t opened, and the generic error message I get when a file randomly disappears doesn’t really tell me much.

I decided to use a twelve-line rclone script to replace the folder-sync job. It works on the same destination, but it applies rules I’ve defined and includes a log that makes the decisions transparent and understandable.

The script had to earn my trust first

Three quiet checks, one log file, zero surprises

Here is the rclone script I’ve turned to:

@echo off
set "SRC=%USERPROFILE%Documents"
set "DST=gdrive:Documents"
rclone sync "%SRC%" "%DST%" ^
--backup-dir "gdrive:Documents_Archive" ^
--exclude "*.tmp" ^
--exclude "~$*" ^
--exclude "desktop.ini" ^
--log-file "%USERPROFILE%rclone-sync.log" ^
--log-level INFO ^
--stats 30s ^
--stats-one-line

It was important to know if I could predict its next move even before using it on anything important. So I ran it with the --dry-run switch. This revealed what files it would modify, create, move, or delete during a real execution without touching the actual files. It was a simple test that turned my script from an experiment to something I could use on real directories.

One of the bigger annoyances I’ve encountered on Windows is the continuous spinning of the drive icon on files I’ve not opened. Office has temporary files that begin with ~$. I didn’t need a remote copy of these; an exclude rule kept these out of transfers. When I ran it for the first time, I looked through the log and saw that the lock file was actually skipped.

Without changing anything on the disk, I re-ran the same job, then checked the log. It was a clean pass, showing zero files transferred. At this point I felt I could trust the script. It was a well-behaved process working as expected.

Then I deleted a file on purpose

What showed up in Documents_Archive changed how I saw the whole job

I chose a document that I use quite often, saved it, closed it, and deleted the local copy. Then I ran the job and opened the remote archive folder after it was completed. I saw the file listed with the same name, and it was complete with the original timestamp. I found all the proof I needed on the log line that recorded this transfer.

The entire mechanism behind this system is simple: the main Documents folder on Drive is matched to the local source (the Documents folder); the archive receives any files that would have been removed or overwritten.

This isn’t a version history mechanism. The archive retains only the most recent previous version of each file. Newer files replace the older ones when the same file name gets archived again. Having just one past version of the file is a limitation that I’ve accepted as a fair trade-off for this simple recovery mechanism.

When I set up this script, I wasn’t aiming at having more copies than Google Drive’s version history, but it gave me real control over disappearing files. I have the instructions in plain text, rather than setting menus that can’t be tweaked beyond a limited set of options.

The magic is in twelve lines of plain text

Every decision rclone made, I could point to exactly why

It’s just a twelve-line script, but each part is relevant for the system to work:

• rclone sync doesn’t blindly re-upload all files; it makes the destination mirror the source by transferring only changed files: rclone sync "%SRC%" "%DST%".
• The backup directory --backup-dir "gdrive:Documents_Archive"is the safety net that preserves files that would otherwise be deleted or overwritten on the destination.
• Three rules exclude noise, like Office files and desktop.ini: --exclude "*.tmp", --exclude "~$*", --exclude "desktop.ini".

The entire behavior is quite simple. When the command runs, rclone compares the source against the destination, and if there are changes, it transfers what’s needed to make the destination match the source. The system’s rules are explicit, and I can edit them as I please. I’ve stopped waiting for a Desktop client to determine how the process works.

This job doesn’t handle renames any better than Google Drive, nor does it replace on-demand streaming or Explorer integration. This script doesn’t touch those separate features.

The twelve-line script is an honest solution with a few tradeoffs

Google Drive is an easier solution. My batch file introduces a component you have to maintain and remember to run. Google Drive also gives you Explorer integration and on-demand features.

However, my rclone script offers a sync job with rules in a text file. I can preview changes and inspect the results afterward; it’s more explicit. I wasn’t trying to improve cloud storage overall; I simply made this part more predictable.