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=CVUb+0RTVooQHLxucFjDyJMq10CpIa9eKH1sMJEpH1ZvVr2htvpxs
	TUTzxzC0Jf8unxfZRyLWvU0/CnUEQuvFcrdMB3gdU+d8P2Vbn8uu8y4Sbqhp/ct4
	SKh7fU822m0+L/0DZbUNRDtBRJKf4Xxnzji6n5yKtDkZAMeGBqJBTQ=
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=JDaHujmSsViVLSx/jl3u/QFp8Sw=; b=IpYXNORpOg32fcQ6sLqaLPxpuCwa
	AqgoqqoFTnh0OhqznqeTFIIa2W9z8sO+BASaS0AL4hAWDgA1a2DXJ9Yyu0JWpUnH
	MjBt5URAiJR7wp/8UIO8+x1YMiQlIAH1qDVGEAiPNjjM+fRzD9GhS7eWASNwwHKF
	fZtFTwL6HpvPc90=
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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 27 Aug 2014 15:47:00 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: (call-process ...) hangs in emacs
Message-ID:	<20140827134700.GJ20700@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<53E39BAD DOT 3010004 AT redhat DOT com> <53E3CB46 DOT 1020909 AT cornell DOT edu> <53E3F2AE DOT 7030608 AT redhat DOT com> <53E4D01B DOT 9010005 AT cornell DOT edu> <53F1F154 DOT 1020702 AT cornell DOT edu> <53FB87DC DOT 2050908 AT cornell DOT edu> <87wq9v9j2y DOT fsf AT Rainer DOT invalid> <53FD0662 DOT 5050208 AT cornell DOT edu> <20140827084245 DOT GD20700 AT calimero DOT vinschen DOT de> <53FDD4A8 DOT 5050401 AT cornell DOT edu>
MIME-Version:	1.0
In-Reply-To:	<53FDD4A8.5050401@cornell.edu>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

On Aug 27 08:52, Ken Brown wrote:
> On 8/27/2014 4:42 AM, Corinna Vinschen wrote:
> >On Aug 26 18:12, Ken Brown wrote:
> >>On 8/26/2014 2:55 PM, Achim Gratz wrote:
> >>>2) Files that have no POSIX permissions (filemode 0000) and where acce=
ss
> >>>is granted via ACL only get always opened as "read-only" and you have =
to
> >>>C-x C-q them before saving.  It appears that this is Cygwin specific
> >>>since on Linux the same version copes with that situation correctly
> >>>(however, the mask bits in the ACL get displayed in the group portion =
of
> >>>the file mode, which I've never seen happen on Cygwin, so this may be
> >>>something that Cygwin needs to do -- maybe that'd even solve the
> >>>problems that Perl has in the same situation).
> >>
> >>AFAICT, emacs decides whether the file is writable via the system call
> >>faccessat.  (See the function 'check_writable' in src/fileio.c.)  This =
is
> >>not Cygwin specific.  So faccessat must be returning failure in the sce=
nario
> >>you described.  I don't know if that's a Cygwin bug or not.
> >
> >faccessat/access/eaccess don't try to be intelligent by themselves.
> >Rather they just call a Windows function if the filesystem is mounted
> >with "acl" mount flags:
> >
> >- Fetch file's security descriptor
> >- Create process impersonation token.
> >- Call NtAccessCheck
> >- If NtAccessCheck returns "not allowed", check for backup/restore
> >   privileges via NtPrivilegeCheck.
> >
> >In "noacl" mode or on filesystems not supporting ACLs, access uses the
> >st_mode flags from stat() to figure out the permissions.
> >
> >The relevant parts of the implementation are the check_file_access and
> >subsequently called check_access functions in security.cc.
> >
> >If you see a bug there, please let me know.
>=20
> Achim, could you send me a recipe for reproducing the problem so that I c=
an
> test further?  Please be very detailed; I have no experience with ACLs.

I'd be interested in a way to reproduce this as well.  On *real* local
or remote NTFS, if possible.

> >>BTW, emacs on Cygwin doesn't directly check ACLs, because the relevant
> >>configure test fails.
> >
> >Works for vim.  Does the Emacs configure test only check for POSIX
> >ACL functions and not for Solaris ACL functions, by any chance?
>=20
> I spoke too soon.  It does detect that Cygwin has certain ACL functions.
> But the feature that Achim was asking about seems to get used only on
> systems that have acl_get_file.  I guess that's a POSIX ACL function.

Yes, it is.  It's pretty much the same as the Solaris/Cygwin function

  int acl (const char *path, int cmd, int nentries, aclent_t *aclbufp);

See http://docs.oracle.com/cd/E23823_01/html/816-5167/acl-2.html for
a description.  We're only supporting the aclent_t type (funny, isn't it?)
which is pretty much based on POSIX ACLs and which is defined in
/usr/include/cygwin/acl.h.


Corinna

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

--svZFHVx8/dhPCe52
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT/eFTAAoJEPU2Bp2uRE+gN6sP/AnFA/DMTDZNIX+UZDWKIS48
f4iVfB+Yw9N/PnJUG5tYYe8z75PHo3/JQd5YSyvvA0sApSilhKuhvasolNFsw4LN
xyPg7Sf5Py3/eNeoysqqhJzUWN5mk6cf7UXfAsJUKFbh0L5AZj5IZnNvrBg9FKue
vEAyd2KwK4FIYQZBvLuEORYLv4py9QtLxvmspFY/cQqx80rgbQFVa8qkt69oSN64
7A854DkC5vVVmM6sKpsO/UwlD1e72APSurcSsKJKP9qGvtQlXNaz5FfJ7BEnJ8uC
Uupq2RZ4/VBOl/UCQxuOCtsBY0c9v2eeS7nRwUWGj48WO8BjC6RjEadElEDJEw6t
sNcAbNAjHnUUluaR3OQt6TgVcAQIO0TRaKBrFJkBMvDOxyapbt/evOEnnEtYXcR1
SJq0pal0dHpNok+MVPnGhwJJ35uuy57Ll+cW4VasDgpHWcgsfPzZE++YSu7NtELh
ZbkgC7YmIHVo9IL+wW6xJXB5/Wn1GhvSlL5kFUPT6RtpTW+ItPPNf1AXnHiluqG1
OXL7qOm7/Sq+vjj8RRrSbAoWms6szWENYEK+OO6Eq/5qzxAMf0c2B5misT/O477H
+koVzB3IvmVSFpRWFnHC43CZcj5oPBoOzh8DfGdPzfAG9g35iIyQ9Twnb3P+5CBq
gkGw7JM9FH+9r9YOohZI
=YLV/
-----END PGP SIGNATURE-----

--svZFHVx8/dhPCe52--

- Raw text -