On Dec 19 17:43, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > On Dec 19 08:29, Eliot Moss wrote:
> >> On 12/19/2018 7:10 AM, Andrey Repin wrote:
> >> > Greetings, Corinna Vinschen!
> >> > 
> >> > > Bottom line is, if you want to handle DOS attributes in a special way
> >> > > not covered by our POSIX emulation, user space has to do it.
> >> > 
> >> > Can something be implemented around getfattr to serve this use case in a more
> >> > POSIX'y way?
> >> 
> >> I was not previously much aware of get/setfattr, but I agree that that looks
> >> like a possible way to provide access to the Windows SYS attribute and friends.
> >> Not that I am that familiar with details of what NTFS, etc., provide, getfattr
> >> may be a way to provide access to additional attributes / facts about files
> >> (paths, generally) as well.  Sounds like it would not be too hard to support
> >> access to the basic attributes this way.
> >> 
> >> I suspect the general response will be PTC, though!  :-)
> 
> > Not only that.  attr is an upstream package, so you would have to 
> > convince the upstream maintainers to take your patches, ideally.
> 
> > attr is for handling of extended attributes, quite different from
> > DOS attributes.  I doubt that DOS attribs fit in there.
> 
> Well, well. We do have a living example of Samba (ab)using xattr to support
> Windows ACL on *NIX.

What are you trying to imply?  That we should fake an user.DOSATTRIB
EA, just like Samba?  Not sure I like the idea since that would have
to be added to each and every file on the fly.  You won't see the
Samba EA from Windows, though.

> I deduce from your response, that a DOS attributes use case would be on
> different side of the table, though.

It's something different.  It's not an EA thingy on Windows but rather
a filesystem property.  So sth. like the vfat IOCTL makes more sense,
if any.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer