Case and Unicode conflicts: when identical-looking names collide and get renamed
2014–2026
Names that are distinct on Dropbox's case-sensitive, Unicode-tolerant servers but identical on Windows or macOS collide on sync, and Dropbox resolves the clash by silently appending '(Case Conflict)' or '(Unicode Encoding Conflict)' to one of the files.
What happened
Dropbox's server namespace is case-sensitive and tolerant of different Unicode encodings, but the Windows and macOS filesystems it syncs to are case-insensitive and normalize names differently. That mismatch produces two recurring classes of conflict.
A case conflict occurs when two items differ only in capitalization — for example a folder named 'records' and another named 'Records'. This is perfectly legal on dropbox.com but impossible on a case-insensitive local filesystem, so when the files sync down, Dropbox appends '(Case Conflict)' to one of them. A Unicode encoding conflict occurs when two names look identical on screen but differ in their underlying Unicode byte representation (such as composed NFC versus decomposed NFD forms of accented characters); these collide on a local filesystem that normalizes them to the same thing, and Dropbox appends '(Unicode Encoding Conflict)' to one.
In both cases Dropbox silently renames a file to avoid losing it. The renamed file is preserved, but its name no longer matches what the user or their software expects.
Impact
Silent renaming breaks links, scripts, and references that depend on exact filenames, and it can leave users with mysteriously duplicated-looking folders whose contents are actually split between two near-identical names. The conflicts are most painful for cross-platform teams and for anyone syncing data created on case-sensitive Linux or on systems using non-Latin scripts, where such collisions are common. As with conflicted copies, the underlying choice — preserve data by renaming rather than lose it — is defensible, but the silent, automatic rename can itself cause real downstream breakage.