This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

BUG: storing ACLS w/Extattrs not working cyginw->linux

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

-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]