Re: Execute permission on Windows XP emacs 22.1

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 9 Jul 2007 14:46:53 +0100
> From: Pete Gillin <pete@void.printf.net>
> Cc: help-gnu-emacs@gnu.org
> 
> > How did you look at the permission bits in your case?
> 
> Using the Security tab of the Properties panel of Windows Explorer.

In that case, it's expected: as you wrote (and I misunderstood), this
is the default for files created on Windows, and Emacs uses the
defaults here.

> (1) When I call set-default-file-modes, the value returned by
> default-file-modes is not what I set (apparently ORed with 177).

This is also expected: the Windows version of `umask' supports only
Read and Write bits for the owner, everything else is stripped away.
So 644 is equivalent to 777, which would explain the apparent ORing
with 177.

> That might well be the cause of the problem I'm seeing. If emacs is
> using the basic API which does not include the "more elaborate access
> permissions" you mention, Windows will be filling in the default
> values, and the default value for Read & Execute is Allow.

Yes.

> It would
> also explain the disparity between what dired shows and what the
> Windows Explorer Property pane shows, because dired isn't reading the
> "more elaborate access permissions" either.

Yes.

> This wouldn't directly explain why there's a discrepancy between the
> the value given to I set-default-file-modes and the value returned by
> default-file-modes, but maybe emacs doesn't bother maintaining an
> execute bit or group/other bits which it knows it can do nothing with
> (using the basic API, as it does).

Emacs doesn't maintain any of these bits, it just calls the `umask' in
the Windows library.  It's `umask' that maintains the bits, and as
explained above, the Windows implementation only maintains two bits:
200 and 400.

So now that we established the reasons for what you saw, is there some
real problem where this (mis)behavior gets in your way?  If the
problem is the Cygwin port of SVN client, then either it has some
workaround for this, or it really means you to use only Cygwin
programs (which presumably manipulate the permissions through the
Windows Security API).  Or maybe you can find a native Windows port of
SVN client, that will not pay attention to the security information.