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

Sebastian Feld <[email protected]>
Newsgroups dev.linux.lists.ntfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel
Message-ID <CAHnbEGJxN9mh7cGN7ycay63F75Z0+_G0fsHm9bgxHesacUrcSA@mail.gmail.com>
On Tue, Aug 4, 2026 at 2:01 AM Namjae Jeon <[email protected]> wrote:
>
> On Mon, Aug 3, 2026 at 6:10 PM Lionel Cons <[email protected]> wrote:
> >
> > On Wed, 29 Jul 2026 at 13:00, Namjae Jeon <[email protected]> wrote:
> > >
> > > Sebastian and Cedric requested NTFS driver support for an interface that
> > > WINE can use to access named data streams.
> > >
> > > NTFS supports multiple named $DATA attributes, commonly known as alternate
> > > data streams, but they are not directly accessible through the existing
> > > file operations. Add NTFS-specific ioctl commands to let userspace list,
> > > 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
-- 
Sebastian Feld - IT security consultant
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.