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