On Jan 16 10:08, Pavel Fedin wrote:
>  Hello!
> 
> > >  What do you think about adding other possible namespaces (system,
> > > security, and... don't remember the 3rd one) ? So that when
> > > manipulating UNIX archives etc these attributes could be kept along
> > > with files ? At least we have one use case now.
> > 
> > That doesn't make sense.  Extended attributes as implemented by Windows
> > are user attributes, not system attributes.  The non-user attributes on
> > Linux have a very special meaning to the kernel and/or are restricted
> > to privileged users only.  Their functionality is already provided by
> > other OS functions (as for system.posix_acl_access) or not at all (as
> > for security.selinux).
> 
>  I know they have special meaning. At the other hand, if we allow
>  them, we will allow to store them on a filesystem. Wouldn't it be
>  nice ? This is useful at least for SquashFS image preparation.
>  I guess for similar reasons we have support e. g. for device nodes
>  (/dev) with their major/minor numbers. They are also ignored by
>  Cygwin, and just stored on the filesystem (or do i miss something ?).

Yes, the history.  The device nodes were a start to implement actual
loadable device handler code (application level, not actual device
drivers), but for some reason it was never fully implemented.

I'm really not inclined to add this.  As it is, the NTFS xattr are
always treated as user attributes.  An NTFS attr "foo.bar" is returned
as "user.foo.bar" and when writing, a "user.foo.bar" is written as
"foo.bar".  Adding other attribute types requires to add some special
casing and parsing code to differ user attributes from other attributes
without breaking backward compatibility.

Also, it will never work correctly on a Samba share, because Samba will
always treat the incoming attribute as above.  So, if you write an
attribute "trusted.md5sum" on a samba share, it will actually be
converted to "user.trusted.md5sum" by Samba.

Another point is stuff like system.posix_acl_access.  It's the
underlying implementation of POSIX ACLs on Linux, so an application
with sufficient access rights could read and write the content directly,
rather than using the system calls.  But the surprise from the
application point of view is, the "system.posix_acl_access" xattrs will
have no effect in terms of permissions.

Having said that, http://cygwin.com/acronyms/#PTC.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat