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