TYO CloudDrive: An Open Source Google Drive Alternative for Linuxeric

There is a particular kind of cloud-storage problem that only appears after you have accumulated years of useful files: you rarely need the whole drive, but you still want the part you are working on to feel local.

For me, that might be a tax folder for one financial year. I want to open it in ordinary Linux tools, add receipts, edit spreadsheets, run scripts, and eventually send the finished folder back to Google Drive. I do not want a background mirror trying to make two entire trees identical while I am still deciding what belongs in the project.

That is why we built TYO CloudDrive, an open-source Google Drive client for Linux. The command is tyocd, and its design is deliberately conservative: browse Drive lazily, check out only the folder you need, and make uploads an explicit, reviewable operation.

Three ways to work with Drive

TYO CloudDrive has three separate modes because browsing, editing, and one-off transfers have different safety requirements.

The important word is separate. TYO CloudDrive is not a background mirror-sync engine. It does not watch your local filesystem and silently propagate every rename or deletion. That makes it a little less magical, but much easier to reason about when the files matter.

Browse without downloading the whole drive

The read-only FUSE mount gives Linux a familiar directory view of Google Drive:

Copy mkdir -p ~/TYOCloudDrive
tyocd mount ~/TYOCloudDrive

Folder metadata is loaded when a directory is listed. A binary file is downloaded only when something opens it, then stored in a private cache and checked against Drive's size and MD5 checksum when available. If Drive's version has not changed, the cached bytes can be reused.

The mount is read-only at several layers. It does not write through changes, rename Drive objects, or delete anything. Google Docs, Sheets, and Slides appear as small link files such as .gdoc, .gsheet, and .gslides, which is more useful than pretending an exported copy is the original document.

There is one honest limitation: opening a binary file currently downloads that file in full. Sparse range caching is not implemented yet. The lazy part is selecting which files to fetch, not fetching only the first few kilobytes of a large file.

Check out one folder as a local workspace

When I am doing real work, the editable workspace is the more interesting feature. Give it a Drive folder ID and a local destination:

Copy tyocd workspace checkout DRIVE_FOLDER_ID /home/me/Documents/Tax

The checkout copies only the selected subtree. TYO CloudDrive keeps an exact-ID manifest in private application state rather than adding metadata files to the project directory. That manifest records the Drive IDs, local checksums, remote versions, and folder relationships needed to tell a genuine change from a confusing filename coincidence.

The normal loop is:

Copy tyocd workspace status /home/me/Documents/Tax
tyocd workspace plan /home/me/Documents/Tax --path 2026 --update
tyocd --yes workspace apply PLAN_ID

The plan is a saved JSON document identified by a SHA-256 digest. Before the first write, apply checks the local files, the exact Drive objects, their versions, and the relevant parent folders. If the cloud copy changed while you were working, the plan becomes a conflict instead of guessing which copy should win.

That is useful for a year-by-year folder. You can prepare 2027 locally, add only the receipts and working files that belong there, inspect the plan, and then upload that scoped subtree. A new local folder can be created in Drive without pulling unrelated changes from 2025 or the rest of the account.

Safety rules that shape the product

The safety model is not a warning printed above an unsafe operation. It is part of the command structure.

• There is no permanent-delete command and no mirror-delete algorithm.
• A remote-only item becomes keep_remote; it is never treated as permission to delete a local copy or vice versa.
• A changed bound file is a conflict unless --update is explicitly supplied.
• Every upload is snapshotted and checksum-verified before mutation.
• Creates use pre-generated Drive IDs, so an interrupted apply can be replayed without making duplicate objects.
• File replacements retain the current binary revision before the conditional update.
• Updates use an HTTP If-Match check so a last-second remote change stops the write.
• A local deletion does not delete the Drive object.

The last rule is especially intentional. A local workspace is a place to work, not a mirror with authority to erase the source of truth.

Open source, and still early

TYO CloudDrive is MIT licensed and available at github.com/tyolab/tyo-clouddrive. It is written in Go and targets Linux. The ordinary CLI and workspace commands do not require FUSE; the optional mount does.

To build it:

Copy git clone https://github.com/tyolab/tyo-clouddrive.git
cd tyo-clouddrive
make build
./bin/tyocd --version

You bring your own Google OAuth desktop client, authorize the scope you need, and then choose whether to browse read-only or use the write-capable workspace flow. The full usage guide explains the commands and the recovery behavior.

This is early alpha software. The core safety model is implemented and tested, but it is still wise to start with a disposable Drive folder and keep an independent backup. Retained Drive revisions and the trash are recovery layers, not a backup strategy.

The goal is modest: make Google Drive feel useful on Linux without making local work feel like a high-stakes synchronization experiment. If you want a whole-account mirror, this is probably not the tool. If you want a small, deliberate part of Drive to behave like a project, that is exactly what we are building.