Cygwin 3.7 wishlist: read/write NTFS alternate data streams via openat(O_XATTR)

[Lionel Cons]

Corinna?

Lionel

On Sat, 5 Apr 2025 at 00:20, Lionel Cons <lionelcons1972@gmail.com> wrote:
>
> On Tue, 1 Apr 2025 at 11:01, Lionel Cons <lionelcons1972@gmail.com> wrote:
> >
> > On Wed, 26 Mar 2025 at 12:30, Corinna Vinschen
> > <corinna-cygwin@cygwin.com> wrote:
> > >
> > > On Mar 25 19:21, Lionel Cons wrote:
> > > > On Tue, 25 Mar 2025 at 17:19, Thomas Wolff <towo@towo.net> wrote:
> > > > >
> > > > > [oops, used wrong Reply function]
> > > > >
> > > > > Am 24.03.2025 um 21:58 schrieb Corinna Vinschen:
> > > > > > On Mar 24 21:42, Thomas Wolff wrote:
> > > > > >>
> > > > > >> Am 24.03.2025 um 17:08 schrieb Jeffrey Altman:
> > > > > >>> On 3/24/2025 10:25 AM, Martin Wege via Cygwin wrote:
> > > > > >>>> Hello,
> > > > > >>>>
> > > > > >>>> another wishlist entry (old one):
> > > > > >>>> read/write NTFS alternate data streams via openat(O_XATTR)
> > > > > >>>  From my perspective as a filesystem developer, Extended Attributes and
> > > > > >>> Alternate Data Streams are different concepts which I believe are
> > > > > >>> inappropriate to mix.
> > > > > >>>
> > > > > >>> Filesystems can implement one, the other, both or neither.
> > > > > >>>
> > > > > >>> An Extended Attribute is a name:value pair that can be attached to an
> > > > > >>> inode. The size of individual values and the sum of the value sizes
> > > > > >>> are often quite constrained because they are stored in the inode
> > > > > >>> metadata. Copying an inode is guaranteed to copy the Extended Attributes.
> > > > > >>>
> > > > > >>> Alternate Data Streams are typically represented as independent
> > > > > >>> inodes. The Alternate Data Stream namespace can be represented by a
> > > > > >>> directory inode referenced from the file inode. Each ADS inode might
> > > > > >>> have their own Extended Attributes to go along with the data stream.
> > > > > >>> ACLs on ADS inodes can also be independent of the ACL on the primary
> > > > > >>> inode depending upon the implementation.
> > > > > >>>
> > > > > >>> Therefore, I am reluctant to see openat(O_XATTR) be used to access
> > > > > >>> alternate data streams.
> > > > > >>>
> > > > > >>> Jeffrey Altman
> > > > > >> Why not use the Windows syntax?
> > > > > >> cat file.txt:ads.txt
> > > > > >> etc. (Was this discussed before?)
> > > > > >> Thomas
> > > > > > The colon is a valid filename character in Cygwin, it will be converted
> > > > > > to the UNICODE private use area:
> > > > > > https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
> > > > > >
> > > > > > Therefore you can't use the colon to specify streams.
> > > > > >
> > > > > >
> > > > > > Corinna
> > > > > OK, so what about a slash? Handling the base file like a directory for
> > > > > access and listing...
> > > >
> > > > ResierFS tried that, and Linus Torvalds personally crushed John Reiser for that.
> > > >
> > > > bash has cd -@ dir and cd -@ file to go into a virtual O_XATTR dir,
> > > > UNIX has /bin/runat to do the same
> > >
> > > In Cygwin, openat is just a frontend to open.  I. e., if we support
> > > openat(O_XATTR), we have to support open(O_XATTR) and define a way to
> > > specify a colon in the filename so that it's not converted to the
> > > UNICODE private use area.
> > >
> > > A preliminary change to the path handling code to disable encoding
> > > the colon is necessary for that.
> > >
> > > With this pretty simple change, openat(fd, "bar", O_XATTR) should work
> > > already,
> >
> > That would be cool...
>
> ... this is not implemented already, right?
>
> Lionel



-- 
Lionel