Re: [REGRESSION] ntfs3: existing files/dirs with ':' in their name became inaccessible in 7.3 (ads on by default)

[Clément Smagghe]

> Hi Konstantin,
>
> Since upgrading from 7.2.11 to 7.3.4, files and directories on an
> ntfs3 volume whose name contains a colon are listed by readdir but can
> no longer be looked up: stat/open/rename/unlink all fail with ENOENT.
> Nothing changed on the volume or in my fstab; the only change is the
> kernel. This is caused by commit be310476e886 ("fs/ntfs3: Add basic
> support for alternative data streams"), merged for v7.3-rc1, which
> enables the new 'ads' mount option by default.
>
> Example (the directory was created on Linux and was perfectly usable
> with 7.2.11):
>
>   $ ls -1b "Game Soundtracks" | grep Reverse
>   Reverse:\ 1999
>   $ ls Rever*
>   ls: cannot access 'Reverse: 1999': No such file or directory
>   $ stat "Reverse: 1999"
>   stat: cannot statx 'Reverse: 1999': No such file or directory
>   $ mv "Reverse: 1999" "Reverse - 1999"
>   mv: cannot stat 'Reverse: 1999': No such file or directory
>
> With 'ads' enabled, ntfs_nls_to_utf16() splits every lookup name at
> the first ':' and treats the rest as a stream name, so "Reverse: 1999"
> is looked up as stream " 1999" of a non-existent file "Reverse". The
> real directory entry is never matched.
>
> Why I think this should be treated as a regression:
>
> 1. Userspace that worked on 7.2 breaks on 7.3 without any
>    configuration change. Names with ':' are legal on NTFS (they exist
>    on volumes written by Linux, by ntfs-3g, by macOS, by WSL, ...),
>    and they are still returned by readdir, so the directory listing
>    and the lookup now disagree with each other. Tools like ls, find,
>    rsync or backup software report errors, and the files cannot even
>    be renamed or deleted to work around it.
>
> 2. There is no obvious way out. The current mount line is:
>
>      /dev/sdb1 on /mnt/HDD_2TB_WD type ntfs3
>      (rw,noatime,uid=1000,gid=1000,dmask=0000,fmask=0000,acl,
>       iocharset=utf8,prealloc,ads)
>
>    'ads' is shown although it was never requested. Following
>    Documentation/filesystems/ntfs3.rst ("You can use every mount option
>    with no option"), I tried 'noads', which is rejected, because the
>    parser only registers fsparam_flag("ads") and fsparam_bool("ads").
>    The only way to get the old behaviour back is 'ads=0', which I only
>    found by reading the commit message.
>
> 3. Silently enabling a new syntax that changes the meaning of an
>    existing, valid file name is also a data safety concern: with a
>    regular file "a" present, an application asking to create "a:b"
>    now writes into a hidden stream of "a" instead of creating a new
>    file.
>
> Could you please make 'ads' opt-in (default off), or at the very
> least make lookup prefer an existing directory entry whose full name
> contains ':' before interpreting the name as file:stream? It would
> also help to accept 'noads' like the other options and document
> 'ads=0' in ntfs3.rst.
>
> Workaround confirmed here: mounting with 'ads=0' makes the entries
> accessible again.
>
> Environment:
>   Linux version 7.3.4-arch1-1 (linux@archlinux) (gcc (GCC) 16.2.1
>   20260810, GNU ld (GNU Binutils) 2.47) #1 SMP PREEMPT_DYNAMIC Wed,
>   11 Nov 2026 19:02:39 +0000
>   Arch Linux, x86_64
>   Last good: 7.2.11 (Arch)   First bad: 7.3.4 (Arch)
>   The Arch kernel carries no ntfs3 patches. I have not built mainline,
>   but in v7.4-rc2 fs/ntfs3/super.c still sets opts->ads = 1 by default
>   and has no "noads" parameter, so the behaviour is unchanged there.
>   The kernel is tainted (OE) by out-of-tree nvidia and tuxedo laptop
>   modules, which are unrelated to the filesystem path involved.
>
> fstab entry:
>   UUID=717D6EE943D0AF06 /mnt/HDD_2TB_WD ntfs3 x-systemd.automount,uid=1000,gid=1000,fmask=000,dmask=000,noatime,exec,rw 0 0
>
> #regzbot introduced: be310476e886
> #regzbot title: ntfs3: names containing ':' inaccessible since ADS support is enabled by default
>
> Thanks,
> Clément Smagghe