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.