X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=CQ+q5lQRofFSTwh0qWEeU0b5C+8ZgGXSMN8PbdsIDI4A08nvaU4im
	cXWg/KGFidPMGbGEQlIfJKVakLZgNFc/OHzRh5DUpsX3NPzXZ2RRG7K5/1u0A147
	Euh322DB4pnC7Zcd8ow0H3JmHTTZnK4SKd9hdIDOhV9QJ15Rlxx6UU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=3jfRyWGsxrkUwbv+n0Lc9g693OM=; b=uEuvpcKzd+cDpqLx7WMkKvVTaK0Z
	4IwS25plCZvv2rNnJ+qu5cGJdrgIi8CuxwfWv5j8yRe5yI3AqF51ux6zsYoe1+9I
	uLI5QJet72kdIJrrbwTHwAManoPdhPgiHsUxIvpfSKl6u7zMNk1ykqKsziNgSdDb
	x6kYnR82TNs42Rk=
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 22 Apr 2015 11:04:40 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.0.0-0.7
Message-ID:	<20150422090440.GB3657@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<announce DOT 20150417103517 DOT GV3657 AT calimero DOT vinschen DOT de> <loom DOT 20150421T111734-742 AT post DOT gmane DOT org> <20150421121559 DOT GY3657 AT calimero DOT vinschen DOT de> <87a8y15rie DOT fsf AT Rainer DOT invalid>
MIME-Version:	1.0
In-Reply-To:	<87a8y15rie.fsf@Rainer.invalid>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--t5UUIFOgpLXgUtsP
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 21 19:18, Achim Gratz wrote:
> Corinna Vinschen writes:
> > It's not about rsync exactly.
>=20
> Well, rsync creates that mess somehow.
>=20
> > The problem is that I'm missing the
> > context a bit.  I take it the permissions are supposed to be inherited
> > from the ".." dir, basically.  The ".." dir has been created by
> > non-Cygwin means, right?
>=20
> Yes, it's the top-level directory of an external disk attached to USB.
>=20
> > The "." dir has been created by Cygwin already
> > it seems, but what permissions were desired?  Does it match the
> > expectations or not?
>=20
> All directories from here on down have been created by Cygwin / rsync,
> and "." is the target directory of the rsync.
>=20
> > The "dir1" and "dir2" directories both have been created by Cygwin,
> > but they are somehow totally wrong.  I don't see how this could occur,
> > even in case the ACL sorting fails at creation time.
>=20
> The problem seems to be that without the --acl flag to rsync, it tries
> to chmod the files it copies to the permissions it gets from the source
> file (which would be ---rwx---+).

Hmm.  Can you try the same with the latest developer snapshot I just
created?  I found this problem which created undesired DENY ACEs,
maybe this was the reason /knock on wood/.

But there's still the fact that the ACL isn't ordered the way Cygwin
intends to do it.  That points to another problem in ACL creation.
Either the ACL created at file creation time already hinders Cygwin
to set it straight afterwards, or the created ACL is missing something
so sorting fails.

> > Btw., the getfacl output of dir1 and dir2 don't seem to match the
> > icacls output.  The groups are different.
>=20
> Yes, that's likely a fallout from rsync trying to recreate the mode bits
> for a different file owner and group.  On the source tree the file owner
> (a domain user) doesn't have any rights, access is granted by one of the
> share groups (seperately for read-only and modify access) and the filer
> admin group (modify access plus a few more permissions).  None of the
> share groups have permission to modify the DACL and everything gets
> inherited from the root node of the share

Oh well.

> (it's a NetApp, but I don't
> think that factors into that problem other than being the standard setup
> on these files apparently).
>=20
> > I wonder if I can create a similar scenario.  Reproducing might be
> > tricky :(
>=20
> Let me know if you need more information.

Thanks,
Corinna

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

--t5UUIFOgpLXgUtsP
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVN2QoAAoJEPU2Bp2uRE+gpvcP/0q/C93UCoUXultg2PD6yXSn
imlG5U0HEyhqllHh1ILZofP7HmQa/oNDeGZywp4wHdoSeXBH0l3eFNmlM9a8BiNS
D6u50LKuvR9eHkTKbqJPC9TIwBNgRExlc3l7p9jprydju4QJkStZVhyasO4H0sQc
mIbGuOdpyeKdVmRliUHS5VVD94ZPQ+xiMbj87bpLU6Kpxoxula88ylodgqOHvGrn
6GnjEEDoT2H2cgViAoPmiNKWPa6dnrMXfpEuT0fcstQf26SfM8RJXx6a1OqmNbcA
SvK+2/zDVtqJKBOa90z000F2d98jvK3svbugySfQXjJm2Tl283+ZlLBwTPbArkUw
sbe2fFkW4sG6Q6pzaZOZGgs52kKmVAIVtf20MMNbesU1VRSAwgsfFiQo/8ELRCdC
UiSR5V31jBds9rR557rkzLltVT8Mdcu7/VHfTopL6DoxVn7yAn9aC8GDDiBXG5nX
V+ZPOiyNM5ryk7RjV0DPcnj//sotvcNVJWAbs2Es6JrdX24XIrinqctpTMcr4b4c
hG1WHqugCajV/hjrd+dVQtSGA+oHjQiExZyv3GFA88mdRLT0N8ejJEhmLqo4sgq/
1OG64Ip5SkeNi1AT4wH5aMHh5zybfbSrlB+g1RH5qh1MeJ11tJFhOMOccR5bByd8
cbOAG5Cn7/HfZikeuoBY
=7snZ
-----END PGP SIGNATURE-----

--t5UUIFOgpLXgUtsP--

- Raw text -