mirror of
https://github.com/tailscale/tailscale.git
synced 2026-07-29 08:46:33 -04:00
420a8e5a1a
Files whose names contain characters with Unicode decompositions (such as umlauts or voiced kana) could not be opened or written over Taildrive. Background: keyboards and IMEs emit NFC (precomposed) characters on every platform, so filenames on Linux (ext4 etc) and Windows (NTFS) disks are usually NFC bytes. NFD (decomposed) names mostly come from Apple software: HFS+ forced a variant of NFD on write, and Apple's frameworks still decompose paths via fileSystemRepresentation. APFS preserves whatever bytes it is given but does normalization-insensitive lookups (it stores a hash of the normalized name), so canonically equivalent names find the same file. ext4 and NTFS lookups, by contrast, are byte-exact. On the wire, the macOS WebDAV client sends paths in NFD form (they pass through the decomposing file system representation, and unlike Apple's NFS client there is no "nfc" mount option). Windows and Linux WebDAV clients pass names through as the application provided them, typically NFC. WebDAV itself mandates no normalization, and PROPFIND hrefs reflect the server's on-disk bytes. The two forms are canonically equivalent but byte-wise different, so a macOS client requesting the NFD form of an NFC-named file on a Linux or Windows host got a 404 from the exact-byte lookup. Even against an APFS host, where the filesystem absorbs the mismatch, the client-side StatCache could still infer a 404: a cached directory listing in one form caused depth 0 PROPFINDs in the other form to be treated as not found without ever reaching the server. The inverse direction (NFD bytes on a Linux disk, copied there from a Mac, requested in NFC form by a Windows or Linux client) was broken too. Alternative regimes considered: normalizing names at storage time (as Nextcloud and Syncthing's autoNormalize do) would rename user files in shared directories as a side effect of serving them; normalizing request paths to a fixed form on the wire is unsound because the on-disk form is unknowable a priori (ext4 can hold either form, or both). Instead, adopt the APFS model: preserve bytes, but make lookups normalization-insensitive. Concretely, wrap the remote file server's webdav.Dir in a normalizingFS that, when an exact path lookup fails, rescans the parent directory for an entry whose name is canonically equivalent, comparing the NFC form of both sides (which also sidesteps Apple's nonstandard decomposition tables). Exact matches always win, and newly created files keep the exact bytes the client sent. Also NFC-normalize StatCache keys so canonically equivalent names share a cache entry. The change is covered at three levels: unit tests for the StatCache, an in-process two-node test in drive/driveimpl, and a new TestTaildrive VM integration test in tstest/natlab/vmtest that shares a directory between two Ubuntu VMs and exercises the NFC/NFD cases over the real stack with curl playing the part of a macOS WebDAV client. Fixes #15020 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com> Change-Id: I9c2f157e604efc629828581e08d5b3191dbb7d4e