OS: Win 11 Education 24H2 (OS Build 26100.8655)
Client: Dropbox Desktop 264.4.3385
Dropbox is always stuck syncing. I've tried everything. I removed all the NTFS Junctions I had and any other problematic folder such as obj & .git directories.
With all those out of the way, it actually started syncing things but eventually STILL got stuck "Syncing "rules.dropboxignore"". I then tried everything to make that file sync, but was unsuccessful.
Eventually I gave up & just made sure the ignore file was configured. Then I recreated all my Junctions & copied all the problematic folders back. The situation is better now, with only 5 files perpetually syncing instead of the 35 or so before.
What prompted me to fix this is because sometimes it'd get so hung up on those 35 or so files my PC wouldn't sync new photos with my phone or files with my Laptop, unless I restarted Dropbox.
I consulted with Gemini while I was working through this issue. I told it generate a summary of everything I tried, done, and observed so I could post it here. Below is what it generated.
Attached is the stripped html of the full convo that goes in real deep with everything tried.
[Removed as per Community Guidelines]
Observed Behavior & Test Progression
1. UI Discrepancy & Log / Database Inspection
- UI Reporting: Despite being permanently stuck in an infinite indexing loop ("Syncing 1 file..." / "Syncing 2 files..."), the Dropbox tray menu UI explicitly reports that there are no sync issues or actionable error flags listed.
- Log Inspection: Checked standard local log directories for explicit error traces, but no relevant indexer exception logs were surfaced.
- Database Analysis: Inspected the local
.db and .sqlite3 database files inside .dropbox.cache and local app data using DBeaver to check for pending operations, locks, or error status flags. No clear indicators or failed sync state entries were surfaced in the local SQLite tables, confirming the deadlock is occurring in memory/driver-level state rather than committing an error record to the local database.
2. Hardlink Junctions & Reparse Points (attrib:L)
- Directories containing NTFS junctions / hardlink reparse points entered a perpetual "Syncing" state in the Dropbox tray menu and context overlay.
- Even after completely removing all hardlink junctions from the local Dropbox directory tree, the indexing queue failed to clear.
3. Directory Isolation & Target Folder Removal
- To rule out heavy payloads or specific nested build artifacts (such as
.git directories or node modules) causing the deadlock, I removed all target directories that were originally intended to be ignored by the rule file. - Even with every target directory physically removed from
U:\Dropbox\, the sync client remained stuck in an indexing/sync loop as long as the rule file structure was engaged.
4. Reserved Filename Handling (rules.dropboxignore)
- The Dropbox desktop client was stuck in a perpetual "Syncing" state.
- Removing the ignore rule file resolved the hang immediately, allowing Dropbox to reach an "Up to date" status.
- Renaming
rules.dropboxignore to rules.dbignore allowed the file to sync normally without hanging the indexer. - Renaming
rules.dbignore back to rules.dropboxignore immediately caused Dropbox to lock up, displaying Syncing 2 files... indefinitely.
5. Testing NTFS Alternate Data Stream (com.dropbox.ignored) Behavior
To test whether the hang was caused by the creation method, I ran the following sequence in PowerShell:
- Created a plain text file named
rules.dbignore and populated it with rules. - Dropbox synced
rules.dbignore without any issues. - PowerShellSet-Content -Path "U:\Dropbox\rules.dbignore" -Stream "com.dropbox.ignored" -Value 1Result: Dropbox immediately got stuck syncing
rules.dbignore. Setting com.dropbox.ignored = 1 directly triggered the sync hang on an otherwise normal, syncable file. - PowerShellClear-Content -Path "U:\Dropbox\rules.dbignore" -Stream "com.dropbox.ignored"Result: Dropbox immediately released the lock and returned to an "Up to date" state.
- PowerShellRename-Item -Path "U:\Dropbox\rules.dbignore" -NewName "rules.dropboxignore"Result: Dropbox instantly got stuck syncing 2 files again.
6. Testing Clean Startup with Pre-Existing ADS Attributes
To determine if this was a race condition caused by live file creation while Dropbox was running:
- Deleted the rule file, waited for Dropbox to sync successfully to an "Up to date" state, and fully exited/killed the Dropbox application.
- Created a new, plain text
rules.dropboxignore file on disk while Dropbox was not running. - PowerShellSet-Content -Path "U:\Dropbox\rules.dropboxignore" -Stream "com.dropbox.ignored" -Value 1
- Launched Dropbox.Result: Upon initialization, Dropbox immediately got stuck on
Syncing 1 file... and remained deadlocked on rules.dropboxignore.
Root Cause Summary
The Windows sync indexer appears to hit a race condition / deadlock when dealing with reserved ignore files (rules.dropboxignore / .dropboxignore) and reparse attributes:
- When Dropbox detects
rules.dropboxignore, it attempts to process it as a system rule file while simultaneously attempting to evaluate/assign the com.dropbox.ignored ADS attribute. - If
com.dropbox.ignored = 1 is set (either automatically by the client or manually via PowerShell), the client attempts to ignore the file that defines its own ignore rules. - The desktop daemon opens/locks an explicit handle on the stream, preventing the indexer from computing the hash or resolving the sync state, resulting in a permanent sync loop that persists even when all target directories and junctions are completely removed.
Questions for Support / Engineering
- Is this a known driver/indexer bug in build 264.4.3385 regarding NTFS Alternate Data Stream evaluation and Reparse Point handling on reserved ignore files?
- Is there a flag or workaround to prevent the client from attempting to set/read ADS attributes on
rules.dropboxignore itself?
