X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 	tests=BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4A990977.1090009@tlinx.org>
Date: Sat, 29 Aug 2009 03:56:55 -0700
From: "Linda A. Walsh" <rsync AT tlinx DOT org>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: rsync <rsync AT lists DOT samba DOT org>
CC: Matt McCutchen <matt AT mattmccutchen DOT net>,
   "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: BUG: storing ACLS w/Extattrs not working cyginw->linux
References: <4A92C315 DOT 5010702 AT tlinx DOT org> <1251175643 DOT 10147 DOT 14 DOT camel AT localhost>
In-Reply-To: <1251175643.10147.14.camel@localhost>
X-Stationery: 0.4.10
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

I didn't explain the problem clearly (as usual, sigh) the first time.

What I was trying to do is transfer from a a cygwin environment using a cygwin
rsync (which should be able to support extended attributes on XFS-based, 
Windows Shares exported with 'samba & the extended attributes'). 

It is my understanding that Samba has specifically added extensions to suport
extended attribute access on remotely mounted XFS shares just as 
the native NTFS files system supports alternate data streams. 

	I was under the impressions that the extended attribute support
was in Cygwin -- and needed to be used in rsync when configured for cygwin.

	Regardless, I had a case of wanting to do

rsync -aH --fake-super <localcyginfs> linuxmachine-w/extended-attrs:/dir

This was what I expected to work -- as, specifically fake-super should have
allowed me to store the NT-ACLS on the target system  (using xfs/w/extattrs)
(which DOES support -- the whole purpose of the switch was to allow storing
ACLS, on a target system in a non-native format so they could be later
recovered when rsynced back from linux->cygwin.

This was what I was trying to support when I was replied to, previously, on the
rsync list:

Matt McCutchen wrote:
> On Mon, 2009-08-24 at 09:43 -0700, Linda A. Walsh wrote:
>> Maybe rsync could support extattrs on non-supporting fs's with a 
>> .<fn>.xattr  file stored >> at the same place as the <fn>:
>>     If a user used a switch to emulate 'xattrs', then on a fs that 
>> didn't support real .xattrs one
>> could still ACL and other .xattr info.  If a user ran rsync w/o that 
>> switch such files would be treated as 'normal files' -- allowing 
>> copying as normal files 
>> between other targets, but allowing ACL restoration on some final 
>> target by re using 
>> the --emulate switch, where it would detect the files on the source,
>> and support the setting of them as ACLS on the target.
> 
> I think the xattr emulation would be more appropriately done in a
> virtual filesystem to be layered over the real one (e.g., with FUSE)
> than in rsync
---
	This wouldn't make sense -- that target system already supports extended file
attributes.  I'm trying to convert from ACL's (not supported on the target system)
to the ext_attrs that are already supported on the target fs.

	My idea for a switch should be superfluous -- at least in part
(depending on the source and target combinations).  Even with extattrs on
a target, I think XFS has a fix-size limit for ext-attr size of around .25M,
so an additional file might still be necessry in the case of very large 
access lists.

As you later mention, on the gnu utils on windows:

> There are getfattr and setfattr for manipulating extended attributes
> from the command line.  Were you thinking of something different?
---
	I was thinking of these being built into rsync the same way they
are used on other platforms.

	Isn't this something that needs to be fixed in the rsync build for
cygwin?


--
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