Re: [PATCH 1/1] ntfs: add ioctl support for named data streams

Sebastian Feld <[email protected]> Tue, 4 Aug 2026 11:10:12 +0200
Newsgroups gmane.linux.file-systems,gmane.linux.kernel
Message-ID <CAHnbEGJxN9mh7cGN7ycay63F75Z0+_G0fsHm9bgxHesacUrcSA@mail.gmail.com>
On Tue, Aug 4, 2026 at 2:01=E2=80=AFAM Namjae Jeon <[email protected]> =
wrote:
>
> On Mon, Aug 3, 2026 at 6:10=E2=80=AFPM Lionel Cons <lionelcons1972@gmail.=
com> wrote:
> >
> > On Wed, 29 Jul 2026 at 13:00, Namjae Jeon <[email protected]> wrote=
:
> > >
> > > Sebastian and Cedric requested NTFS driver support for an interface t=
hat
> > > WINE can use to access named data streams.
> > >
> > > NTFS supports multiple named $DATA attributes, commonly known as alte=
rnate
> > > data streams, but they are not directly accessible through the existi=
ng
> > > file operations. Add NTFS-specific ioctl commands to let userspace li=
st,
> > > read, write, and remove named data streams on an opened file.
> > >
> > > The new UAPI provides separate commands for each operation:
> > >
> > >   - NTFS_IOC_STREAM_READ
> > >   - NTFS_IOC_STREAM_WRITE
> > >   - NTFS_IOC_STREAM_REMOVE
> >
> > Wouldn't it be better to just provide an API to get a fd, relative to
> > a filename? Win32 named streams can be sparse, and it is common to
> > punch holes to deallocate sections of streams too. Streams do have
> > their own timestamps, too.
> I believe the current ioctl interface is the best fit for this
> support. It operates on an already-open base-file fd, avoids pathname
> ambiguity with :,

Nope, NFS already fixed this by allowing "unnamed" fd for deleted
files. Not having a name is OK. Win32 uses
"filename:streamname:$DATA", if any resolving is needed. That works,
because the Win32 API and NTFS forbit ':' within file and dir names.

> supports UTF-16 stream names, and does not require a
> new system call or VFS changes. If WINE requires hole punching for
> sparse streams, I can extend the ioctl interface to support it.

Wearing my hat as the one who has to do the WINE implementation side:
I think a fd with all normal file operations available is the better
option, because we need to do per stream: read(), write(), fsync(),
fdatasync(), sync_file_range(), file locking for each stream
separately, mmap(), getting/setting timestamps, futimes(), fstat(),
ftruncate(), lseek() SEEK_HOLE,SEEK_DATA, fallocate() for space
allocation/deallocation, unlink(), ... and likely more. Pretty much
every syscall, except mkdir(),mknod(),rmdir().

Sebi
--=20
Sebastian Feld - IT security consultant