Cloud Sync (google_drive): concurrent folder creation creates duplicate same-name folders; files split between twins and sync stalls
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.1k
- Forks
- 2.2k
- Avg merge
- 7h 35m
- Merged PRs (30d)
- 51
Description
Is there an existing issue for this?
- This is a bug in RetroArch frontend
- I have searched the existing issues
Description
The google_drive cloud sync backend creates duplicate sibling folders with identical names when multiple uploads targeting the same missing folder run concurrently. Google Drive permits same-named siblings, so both "check missing → create" calls succeed. Because folder lookup requests only one match (&fields=files(id)&pageSize=1 in the folder lookup), subsequent syncs non-deterministically resolve to either twin — files end up split across both, the manifest disagrees with whichever twin is consulted, and sync sessions stall (persistent "Cloud Sync in progress 0%").
Evidence (Drive API createdTime metadata from an affected account)
Duplicate twins were created 41–148 ms apart, on three separate dates, including with the 2026-07-22 nightly — so the race is alive in master:
| Folder (parent) | Twin 1 created | Twin 2 created | Δ |
|---|---|---|---|
config (RetroArch/) |
2026-06-23T10:57:26.008Z | 2026-06-23T10:57:26.049Z | 41 ms |
Azahar (saves/) |
2026-06-24T19:53:13.860Z | 2026-06-24T19:53:13.903Z | 43 ms |
Mupen64Plus-Next (config/) |
2026-07-22T05:08:51.723Z | 2026-07-22T05:08:51.849Z | 126 ms |
remaps (config/) |
2026-07-22T05:09:02.651Z | 2026-07-22T05:09:02.799Z | 148 ms |
Observed consequences on the same account: FinalBurn Neo, Mesen, melonDS DS, Mupen64Plus-Next core config folders exist in both config twins with contents split between them; sync sessions stall at 0%; one crash occurred immediately after completing the OAuth device flow on Android (1.22.2 nightly 2026-07-22, aarch64) — plausibly the same manifest/folder-tree confusion, though not yet isolated.
Environment
- RetroArch 1.22.2 nightly (2026-07-22), Android aarch64, google_drive backend
- Duplicates also created by late-June 2026 nightlies (see table)
- Sync: Saves + Configuration Files enabled (initially also Thumbnails/System)
Reproduction
- Fresh Drive account (or empty RetroArch folder), google_drive backend
- Enable sync for saves + configs with content across many per-core subfolders
- Trigger the first "Sync Now" so many uploads with missing parent folders run concurrently
- Inspect Drive: duplicate same-named sibling folders appear (ms apart)
Suggested direction
Serialize folder resolution/creation (single-flight per path via the folder cache added in "cloud sync: allocate the drive folder cache on first use"), or pre-resolve/create the folder tree before enqueueing file transfers. Detecting existing same-name siblings during lookup (pageSize>1 + warn/merge) would also make the backend self-healing for already-affected accounts.
Happy to test patches on affected devices.
Transparency: this report was investigated and drafted with AI assistance (Claude); the evidence is from my own Google Drive account.
Expected behavior
Each folder name should exist exactly once per parent; files should upload into a single canonical folder tree, and sync should complete to a consistent state across devices.
Steps to reproduce the bug
- Use the google_drive Cloud Sync backend against a fresh Drive account (or empty RetroArch folder)
- Enable sync for saves + configuration files, with content spread across many per-core subfolders
- Trigger the first "Sync Now" so many uploads with missing parent folders run concurrently
- Inspect the Drive folder tree (web UI or API): duplicate same-named sibling folders appear, created milliseconds apart; on later syncs, files split between the twins and sync sessions stall at 0%
Version/Commit
1.22.2 nightly 2026-07-22 (Android aarch64); duplicates also produced by late-June 2026 nightlies
Bisect Results
No response
Present in the nightly version
Yes, this is reproduced in the nightly build
Platform & operating system
Android 14, aarch64 (phone/tablet; multiple devices affected)
Affected Cores
No response
Environment information
No response
Relevant log output
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the google_drive backend's concurrent folder lookup and creation, including the folder cache added by "cloud sync: allocate the drive folder cache on first use." Reproduce an initial sync with many missing per-core folders, then verify that each parent has one same-named child, files use one canonical tree, and sync completes consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- backend, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100