From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29659 invoked by alias); 20 Jan 2014 05:22:08 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 29648 invoked by uid 89); 20 Jan 2014 05:22:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_20,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mailout4.w1.samsung.com Received: from mailout4.w1.samsung.com (HELO mailout4.w1.samsung.com) (210.118.77.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Mon, 20 Jan 2014 05:22:06 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MZO00KWOPKQSQ20@mailout4.w1.samsung.com> for cygwin@cygwin.com; Mon, 20 Jan 2014 05:22:02 +0000 (GMT) Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id BF.F8.23059.972BCD25; Mon, 20 Jan 2014 05:22:01 +0000 (GMT) Received: from fedinw7x64 ([106.109.9.113]) by eusync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0MZO00700PKJD180@eusync1.samsung.com> for cygwin@cygwin.com; Mon, 20 Jan 2014 05:22:01 +0000 (GMT) From: Pavel Fedin To: cygwin@cygwin.com References: <006e01cf1066$c5f0e080$51d2a180$%fedin@samsung.com> <20140113141041.GC21977@calimero.vinschen.de> <002f01cf11ba$df28b550$9d7a1ff0$%fedin@samsung.com> <20140115091530.GH10212@calimero.vinschen.de> <001701cf1281$5fc57150$1f5053f0$%fedin@samsung.com> <20140116091600.GC26205@calimero.vinschen.de> In-reply-to: <20140116091600.GC26205@calimero.vinschen.de> Subject: RE: Extended attributes Date: Mon, 20 Jan 2014 05:22:00 -0000 Message-id: <006301cf159f$8c0c8d90$a425a8b0$%fedin@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00260.txt.bz2 Hello! > 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. >=20 > 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. Sorry for late reply, too busy at work now... The same about NFS-related p= ackages - no time ATM to make them... :( You know, i got your point, and perhaps this can be rethought. Perhaps thi= s can be done on SquashFS side. For example, we could tell it to store 'sec= urity.foo' attribute as 'user.squashfs.security.foo'. This could be also us= eful on Linux, because in this case you don't have to be root any more to b= e able to prepare a rootfs for your embedded device. I think i'll consider that after i finish up with NFS. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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