Execute permission on Windows XP emacs 22.1

Execute permission on Windows XP emacs 22.1

[Pete Gillin]

OS: Windows XP Pro / SP2
Emacs: This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02
on RELEASE

Can anyone explain to me why emacs refuses to create files without
"Read and Execute" permission set (for the creating user)? I tried
things like the following in my startup file, to set the value and
allow me to inspect it immediately after setting (by looking at the
variable) and at runtime (by running the insert function).

(set-default-file-modes ?\644)

(setq my-default-file-modes (number-to-string (default-file-modes)))

(defun insert-default-file-modes ()
  "inserts current value of default-file-modes"
  (interactive)
  (insert (number-to-string (default-file-modes))))

Both ways of checking the value agree, and suggest that the value I
have tried to set has been immediately ORed with 177 (octal). In the
above case, when I've tried to set 644, the value actually set is 777.
And looking at the file properties confirms that "Read and Execute" is
set for the creating user whatever modes I've asked for. Which is
unhelpful, frankly.

Thanks,

Pete.

P.S. I know that the normal behaviour on Windows is to make everything
executable by default --- but I don't see why emacs should insist on
doing this when I've explicitly asked it not to. The reason this
bothers me (if you're curious) is that I'm using the Subversion
version control system (the cygwin client) and when I add a file which
has "Read and Execute" locally, it automatically sets the repository
property svn:executable and so (if I forget to unset it) we get the
executable bit set on all working copies (including linux where it
matters more).

P.P.S. The behaviour seemed to be even odder on emacs 21.3, but I
didn't investigate thoroughly.

Re: Execute permission on Windows XP emacs 22.1

[Eli Zaretskii]

> Date: Mon, 9 Jul 2007 10:14:27 +0100
> From: Pete Gillin <pete@void.printf.net>
> 
> OS: Windows XP Pro / SP2
> Emacs: This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02
> on RELEASE
> 
> Can anyone explain to me why emacs refuses to create files without
> "Read and Execute" permission set (for the creating user)?

I don't see this, or maybe I don't understand how exactly did you try
this.  Would you please show a step-by-step recipe, starting with
"emacs -Q", to reproduce this problem?

On my machine (also an XP SP2), Emacs by default creates files that
have only Read and Write permissions set; no Execute permission.  I
look at the permission bits by running Dired on the parent directory.
How did you look at the permission bits in your case?

> I tried
> things like the following in my startup file, to set the value and
> allow me to inspect it immediately after setting (by looking at the
> variable) and at runtime (by running the insert function).
> 
> (set-default-file-modes ?\644)
> 
> (setq my-default-file-modes (number-to-string (default-file-modes)))
> 
> (defun insert-default-file-modes ()
>   "inserts current value of default-file-modes"
>   (interactive)
>   (insert (number-to-string (default-file-modes))))
> 
> Both ways of checking the value agree, and suggest that the value I
> have tried to set has been immediately ORed with 177 (octal). In the
> above case, when I've tried to set 644, the value actually set is 777.

Is the problem only with default-file-modes and set-default-file-modes? 
Or do you really see files created with wrong permissions?

If the problem is with default-file-modes and set-default-file-modes,
then it could be a bug with just these two functions, or it could be a
problem with your usage of them (or both).  In particular, you need to
be aware that the Windows implementation of the `umask' library
function, which is what these two Lisp functions call, does not
support the Execute bit (it masks it off, as if you never set it in
the argument to `umask'), and it also zeroes out the lower 6 bits of
the mask, i.e. it uses only the owner's bits, because the Windows
filesystem has only one set of permissions, not 3 sets as on Unix.
(Well, actually, the last part is not 100% true: NTFS volumes do
support much more elaborate access permissions on Windows NT and its
descendants, but Emacs does not call the APIs necessary to make use of
these features.)

> And looking at the file properties confirms that "Read and Execute" is
> set for the creating user whatever modes I've asked for.

Please describe how did you look at them, exactly.

> P.S. I know that the normal behaviour on Windows is to make everything
> executable by default

No, it isn't.  The default is to make files with read and write
permissions.  The executable permission isn't maintained as part of
the bits returned by `stat' and similar functions.

> P.P.S. The behaviour seemed to be even odder on emacs 21.3

I see the same behavior there, but again, I might be using a wrong
sequence of commands, not the one you used.

Re: Execute permission on Windows XP emacs 22.1

[Pete Gillin]

On Mon, Jul 09, 2007 at 03:19:52PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 9 Jul 2007 10:14:27 +0100
> > From: Pete Gillin <pete@void.printf.net>
> > 
> > OS: Windows XP Pro / SP2
> > Emacs: This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02
> > on RELEASE
> > 
> > Can anyone explain to me why emacs refuses to create files without
> > "Read and Execute" permission set (for the creating user)?
> 
> I don't see this, or maybe I don't understand how exactly did you try
> this.  Would you please show a step-by-step recipe, starting with
> "emacs -Q", to reproduce this problem?

See below for two procedures showing what I tried.

> On my machine (also an XP SP2), Emacs by default creates files that
> have only Read and Write permissions set; no Execute permission.  I
> look at the permission bits by running Dired on the parent directory.
> How did you look at the permission bits in your case?

Using the Security tab of the Properties panel of Windows Explorer.

[snip]
> Is the problem only with default-file-modes and set-default-file-modes? 
> Or do you really see files created with wrong permissions?

As I show below, I see two parts to this problem.
(1) When I call set-default-file-modes, the value returned by
default-file-modes is not what I set (apparently ORed with 177).
(2) When I create a file with emacs, dired shows no execute bit, but
Windows shows a checkmark under Allow for Read & Execute. This happens
whether I create the file with runemacs -Q, or using a load file which
does set-default-file-modes \?644.

The second of these is the one that I really care about.

> If the problem is with default-file-modes and set-default-file-modes,
> then it could be a bug with just these two functions, or it could be a
> problem with your usage of them (or both).  In particular, you need to
> be aware that the Windows implementation of the `umask' library
> function, which is what these two Lisp functions call, does not
> support the Execute bit (it masks it off, as if you never set it in
> the argument to `umask'), and it also zeroes out the lower 6 bits of
> the mask, i.e. it uses only the owner's bits, because the Windows
> filesystem has only one set of permissions, not 3 sets as on Unix.
> (Well, actually, the last part is not 100% true: NTFS volumes do
> support much more elaborate access permissions on Windows NT and its
> descendants, but Emacs does not call the APIs necessary to make use of
> these features.)

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

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

> > And looking at the file properties confirms that "Read and Execute" is
> > set for the creating user whatever modes I've asked for.
> Please describe how did you look at them, exactly.

I used the Security tab of the Properties panel of Windows Explorer.

> > P.S. I know that the normal behaviour on Windows is to make everything
> > executable by default
> No, it isn't.  The default is to make files with read and write
> permissions.  The executable permission isn't maintained as part of
> the bits returned by `stat' and similar functions.

Sorry, I didn't mean the normal behaviour of emacs, I meant the common
behaviour of Windows applications. I created a file with WordPad, to
see what would happen, and it did have Read & Execute set to Allow.

Thanks for helping look into this.

Pete.

PROCEDURE A (simple)

On the command line, I do 'runemacs -Q myfile'.

I make an edit and save the file.

I inspect the current directory with dired (M-x dired). It shows
myfile with permissions of -rw-rw-rw-, in line with what you suggest.

I open Windows Explorer. On myfile, I right click and open Properties.
I go to the Security tab. For all users, there are checkmarks under
Allow for the Read & Execute permission.

PROCEDURE B (using a load file)

I have the following in dfm_stuff:

-----begin dfm_stuff-----

(set-default-file-modes ?\644)

(setq my-default-file-modes (number-to-string (default-file-modes)))

(defun insert-default-file-modes ()
  "Insert current default-file-modes"
  (interactive)
  (insert (number-to-string (default-file-modes))))

-----end dfm_stuff-----

On the command line, I do 'runemacs -Q --load=dfm_stuff myfile2'. (I
realise that reproducing with -Q is easier, but in this case I had to
do the set-default-file-modes in a load file because it is not
available interactively --- please let me know if there's a better way
to do this.)

Note that the first line above tries to set to 644 octal.

I check the value of default-file-modes immediately after it was set,
stored in a variable by the second line above. I typed 'C-h v
my-default-file-modes'. It showed a value of 511, which is 777 octal.

I check the current value of default-file-modes using the function
defined in the third line above. I typed 'M-x
insert-default-file-modes'. It inserted 511, which is 777 octal.

I inspect the current directory with dired (M-x dired). It shows
myfile2 with permissions of -rw-rw-rw-, in line with what you suggest.

I open Windows Explorer. On myfile2, I right click and open Properties.
I go to the Security tab. For all users, there are checkmarks under
Allow for the Read & Execute permission.

Re: Execute permission on Windows XP emacs 22.1

[Eli Zaretskii]

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

Re: Execute permission on Windows XP emacs 22.1

[Pete Gillin]

On Mon, Jul 09, 2007 at 05:42:24PM +0300, Eli Zaretskii wrote:
> 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.

Okay, that makes sense.

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

Adding new files using the cygwin port of svn is the only time this
causes a problem for me. It's not a big deal, so if the only fix is
for emacs to start using the more advanced API and that's not likely
to happen soon then I'll live with it.

(I could use the native Windows svn client, but (for various reasons)
the convenience of the cygwin version outweighs the minor
inconvenience of having to unset the executable bit on new files. Or I
guess I could try the cygwin port of emacs which might go through
cygwin and so control the full permissions properly, but I don't
always use emacs from cygwin and I don't want to confuse myself with
two different versions.)

Glad we've cleared that up. Thank you.

Pete.