This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Extended attributes
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 16 Jan 2014 13:52:44 -0500
- Subject: Re: Extended attributes
- Authentication-results: sourceware.org; auth=none
- References: <006e01cf1066$c5f0e080$51d2a180$%fedin at samsung dot com> <20140113141041 dot GC21977 at calimero dot vinschen dot de> <002f01cf11ba$df28b550$9d7a1ff0$%fedin at samsung dot com> <20140115091530 dot GH10212 at calimero dot vinschen dot de> <001701cf1281$5fc57150$1f5053f0$%fedin at samsung dot com> <20140116091600 dot GC26205 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
On Thu, Jan 16, 2014 at 10:16:00AM +0100, Corinna Vinschen wrote:
>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.
If you're talking about the ability to create a device file anywhere
that was something that I did. It wasn't to implement loadable device
handlers but just so that we could eventually have a real /dev populated
with device files. However, we have since gone the route of creating a
pseudo-filesystem /dev so that's no longer necessary.
I also did this to allow the creation of fifos anywhere so that's still
a valid use case. And, actually, creating a device node anywhere is
certainly something that you need to be able to do if you want to claim
Linux-like functionality.
Device nodes are not (or are not supposed to be) "ignored by Cygwin".
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple