Why Do Case-Only Filenames Collide During a Cross-Platform NAS Restore?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Why Do Case-Only Filenames Collide During a Cross-Platform NAS Restore? - Zima Store Online

Case-only filename conflicts appear during a cross-platform NAS restore when the backup contains two paths that the restore destination considers equivalent. A Linux home server may preserve Photo.jpg and photo.jpg as separate files, while a Windows volume, a default macOS volume, or an SMB client may treat those names as one destination. The restore tool then has to overwrite, rename, skip, merge, or stop.

Do not continue the full restore until you know which paths collided and how the tool handled them. Restore the affected tree into an isolated staging location, preserve both source objects under deterministic temporary names, and create a path-mapping record before moving data into the live NAS share.

Why Can the Backup Store Two Names That the Restore Target Rejects?

A backup repository can record paths as opaque names without enforcing the destination filesystem's comparison rules. Linux filesystems commonly distinguish uppercase and lowercase, while Windows and default macOS filesystems commonly preserve the typed case but compare names without case distinctions. A cross-platform restore discussion shows that source paths may be valid in the backup but unrepresentable on the restore system.

For a home NAS, this often happens after restoring a Linux container volume, developer directory, photo import tree, or media library onto a share that will be accessed from Windows or macOS. The backup is not necessarily corrupt; the destination namespace has a smaller set of distinct names.

Case-Preserving SMB Is Not the Same as Case-Sensitive Storage

An SMB share may display the original capitalization and still perform case-insensitive lookup. A TrueNAS community example describes different case rules at the dataset and SMB access layers. The server may therefore store mixed-case names locally while a Windows or macOS SMB client cannot address them as separate objects.

Test the actual restore path, not only the NAS filesystem setting. Create two harmless files whose names differ only by case through the same client, protocol, mount, and destination directory that the restore job will use. If the second creation fails or resolves to the first file, that path cannot safely receive the original tree unchanged.

A Folder-Name Collision Can Merge an Entire Subtree

The conflict may occur in any directory component, not only the final filename. If the backup contains Photos/2025/A.jpg and photos/2025/B.jpg, a case-insensitive destination may merge both branches into one directory or reject the second branch. A mixed Linux-and-Windows transfer account shows how directory-component collisions can misroute or discard files.

Compare full relative paths after applying the destination's case-folding rules. A report that checks only duplicate basenames can miss collisions created by parent directories.

Restore Tools Do Not Handle Every Collision Safely

A restore application may stop with an “already exists” error, append a suffix, keep the first file, keep the last file, or merge directory trees. Some jobs still finish with a success or warning state even though one member of a collision pair was skipped. Research into inconsistent handling of case-sensitivity-induced collisions shows why the tool's behavior must be observed rather than assumed.

Before a large restore, build a small test backup containing file and directory pairs that differ only by case. Record whether the tool fails, renames, overwrites, or merges, and verify both content hashes afterward.

Unicode Normalization Can Produce a Similar Collision

Two filenames can look identical while using different Unicode code-point sequences, such as a precomposed accented character and a base character followed by a combining mark. APFS name handling preserves forms while using normalized comparisons in some modes, and case sensitivity and Unicode normalization interact in filename lookup.

Do not assume that every apparent case-only conflict is caused only by uppercase and lowercase. Export names in an escaped or code-point-aware format when accented, Asian-language, or visually identical names are involved.

Freeze the Restore and Preserve Both Objects First

When a collision appears, stop restoring into the live destination. Do not repeatedly rerun the same job with overwrite enabled, because the winner can change with traversal order. Create a case-sensitive staging filesystem or restore through a Linux environment that can represent both names. A Windows command-line article explains that case-sensitive directories can preserve names that ordinary Windows applications cannot distinguish, illustrating why staging must use a namespace that can represent both objects.

Restore each colliding object to a unique temporary name such as Photo.jpg.__case1 and photo.jpg.__case2. Keep the original path, backup version, size, checksum, and selected temporary name in a CSV or JSON mapping file.

Rename Collisions Deterministically Before Moving Them to the Live Share

Choose a rule that never depends on which file is encountered first. Add a source-platform label, stable hash fragment, or explicit sequence while preserving the extension. For example, keep Photo__linux_A1B2.jpg and photo__linux_C3D4.jpg rather than accepting automatic “copy” suffixes whose meaning is unclear.

Review the mapping before changing names in the backup repository or original source. The ZimaSpace guide to detecting case-sensitive filename collisions before a cross-platform copy can be used to scan the reconstructed staging tree and confirm that no unresolved pair remains.

Repair Application References After Renaming Files

A renamed media file may disappear from a library database, a container configuration may point to the old path, and a photo application may treat the renamed object as a new asset. Restore data first, then update playlists, sidecar links, scripts, database records, bind mounts, and application indexes that depend on exact spelling.

For self-hosted applications, preserve the database and configuration that describe the original paths. A filesystem-only restore can retain every byte but still leave the application incomplete when path references no longer match.

Use a Collision Report to Decide the Recovery Action

Observed Result	Likely Cause	Safe Recovery Action
Second file reports “already exists”	Destination compares names case-insensitively	Restore both to case-sensitive staging and rename deterministically
Two source folders appear as one	A parent directory differs only by case	Compare normalized full paths and split the merged subtree
Restore completes but object count is lower	Tool skipped or overwrote one collision member	Review collision logs and compare path inventory plus hashes
Names look identical but case differs are absent	Unicode normalization or unsupported characters	Inspect escaped code points and normalize through staging
Files exist but an app cannot find them	Renaming broke exact path references	Update application metadata, indexes, and container mounts

FAQ

Can an SMB share preserve both `File.txt` and `file.txt`?

Only when the underlying dataset, SMB server configuration, client, and application all use compatible case-sensitive semantics. A case-sensitive NAS dataset alone does not prove that every SMB client can create and address both names.

Does restoring to a case-sensitive APFS volume solve every conflict?

No. It can preserve case-only pairs, but the later SMB destination, Windows client, application, archive format, or Unicode comparison rules may still collapse or reject the names.

Why can two visually identical filenames still conflict?

They may use different Unicode sequences that a destination normalizes to the same comparison form. Inspect code points rather than relying only on how Finder or Explorer displays the name.

Final Takeaway

Case-only filename collisions occur because a backup can preserve more distinct path names than a cross-platform restore destination can represent. Stop at the first collision, restore into a compatible staging area, preserve every object under deterministic temporary names, record a mapping, and validate counts and checksums before importing the data into a live home NAS share.