Build1 publisher3 min readPublished
Writing in place keeps the Drive file ID that os.replace() resets on a Drive for Desktop mount
One developer's sync script for Google Drive for Desktop overwrites its shared file in place, after a temp-file rename gave the file a new Drive ID. Dropping the rename keeps the ID with no OAuth or network calls, at the cost of a mid-write window and any check for edits made elsewhere.
The Engineer · Build desk
What happened
- A developer found that writing a temp file and calling os.replace() on a Google Drive for Desktop mount keeps the file's name but gives it a new Drive file id.
- The fix overwrites the shared file through its existing file descriptor, and the id now survives every push with no gws auth or network calls.
- Before writing, the script compares device and inode numbers from lstat and fstat and aborts if the file was swapped between the check and the open.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Anything that addresses a mounted file by its Drive file id loses track of it after a rename-based save, while the local file looks unchanged.
- decision Picking the mount path over the gws route trades away OAuth and API dependencies and, with them, requiredRevisionId conflict detection on the shared file.
- cost Whoever edits the shared file from another machine can lose that edit to the next push, because the lock only keeps the script's own runs apart.
The author already had a heavier route to Drive. memory-cloud-sync.py goes through gws, the Google Workspace CLI, with OAuth, the Drive API, Docs API batchUpdate and compare-and-swap conflict checks via requiredRevisionId [7]. The mount script drops all of it. Drive for Desktop already mounts My Drive under ~/Library/CloudStorage on the author's Mac, so a file written there syncs without the script touching auth or the network [10][3].
That only works if the local file stays the object Drive already knows. The function's docstring states the rule: "Deliberately never os.replace(): the mount file's identity (e.g. a Google Drive file id behind the local inode) must be preserved rather than swapped for a new one." [12] The inode explanation is the author's, based on one Mac [2][10]. It carries over wherever Drive for Desktop ties a file id to the local file object the same way. On a mount like that, any tool that saves through a temp file and a rename would get the same new id [5].
The write itself is careful, and the inode comparison is the part I would copy. An lstat check confirms the path is a regular file and not a symlink. The function then opens the path read-write, with O_NOFOLLOW where the platform offers it, and calls fstat on the descriptor. If the (st_dev, st_ino) pair differs from the lstat result, the file was swapped between check and open, and the function raises mount_target_changed_during_write [5]. Only then does it seek(0), write, truncate, flush and fsync [4].
Between write and truncate, the bytes change under the same inode. If the new snapshot is shorter than the old one, the old tail stays after the new content until truncate runs [2]. The post does not say what Drive for Desktop uploads if it reads the file in that window.
Concurrency is the second cost. Without the Drive API there is no competing-write detection of the requiredRevisionId kind, as the author notes [8]. flock and the single-run lock keep two runs of the script from colliding [8][11]. They cannot see an edit that reached SHARED-MEMORY.txt through Drive from another machine, and the next push writes over it [4].
The guard I like best is a refusal. If SHARED-MEMORY.txt is missing, a symlink or not a regular file, the push stops with a non-sensitive error code [6]. Creating the file would work perfectly and break the one thing the script exists to protect. The code comment says a new file "would mint a new Drive file id in place of the shared one" [13].
On the pull side, the script is bounded the same way: date-named .txt, .md or .markdown notes only, at most 50 files at 256KB each, staged in quarantine under AI/INBOX/cloud [9]. One run can stage at most 12,800KB [1].
What to watch
- A Windows test or Google documentation showing whether Drive for Desktop ties file ids to the local file object outside the author's Mac.
- Any report of what Drive for Desktop syncs when it reads SHARED-MEMORY.txt mid-overwrite: a partial upload or a clean revision.
- Whether the mount path adds a pre-push check for edits made elsewhere, the gap requiredRevisionId covers on the API route.