Skip to content

Google Drive for desktop: mv inside the mount keeps the uploaded object, and a folder you just created is invisible to the item-id index

Two behaviors of the macOS Google Drive FileProvider mount that matter when a script stages files into it and then verifies delivery. Both observed 2026-09-03, Drive for desktop on macOS 26, Shared Drive mounted under ~/Library/CloudStorage/GoogleDrive-<acct>/Shared drives/<name>.

1. A rename/move within the mount is a server-side metadata op, not a re-upload

A 42,331,550-byte file already uploaded under a wrong name and folder had to move to a new folder under a canonical name. mv inside the mount returned instantly and the file kept its server object: the ground-truth check (the com.google.drivefs.item-id#S extended attribute, which Drive writes only after the server accepts a file) was present on the destination path immediately.

mkdir -p "$MOUNT/6-posted"
mv "$MOUNT/3-post/<hex>.MOV" "$MOUNT/6-posted/<canonical>.mov"   # instant
xattr -p 'com.google.drivefs.item-id#S' "$MOUNT/6-posted/<canonical>.mov"  # present at once

Contrast a genuinely new 18,707,190-byte file rsynced into the same folder in the same minute: no item-id xattr for ~10 seconds while it uploaded.

Consequence for pipelines: to fix a name or a folder for content already on Drive, move it on the mount. Do NOT re-copy from local and do not rely on your sync command to clean up. rsync --ignore-existing (archive semantics) will never re-push a corrected name, and rsync never deletes, so a local rename alone leaves the old name on Drive forever as an orphan. Rename on both sides.

2. A folder created directly on the mount is not yet in the local index

Tooling that reads Drive state without walking the mount (item-id xattrs, or the local Drive metadata store) does not see a folder created seconds earlier, and reports it as nonexistent — while plain ls on the mount lists it and its contents correctly. Same second, same path: index lookup not found: 6-posted; ls -la "$MOUNT/6-posted/" printed the moved file at full size.

So do not use an index/xattr-based existence check as the verification step for a freshly created directory. Verify the FILES (xattr per file) and let a bounded ls with a timeout confirm the directory. Keep the timeout: listing an unmaterialized Drive folder can hang for minutes, which is the reason such tooling avoids the mount in the first place.

No signals yet