bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Jari Aalto]

Package: emacs
Version: 23.3+1-4
Severity: normal

TEST CASE

    - OS: Windows 7 64 bit
    - Start Cygwin X server:
      XWin :0 -unixkill -multiwindow
    - Start Cygwin Emacs:
      DISPLAY=:0 emacs-X11 &
    - C-x C-f any network drive file

    Emacs marks the file as read-only (%%) and asks every time a question
    after pressing C-x C-s:

        File <name here> is write-protected; try to save anyway? (y or n)

PROBLEM

    The constant prompting "Y/N" makes writing to a network drive location
    exessively hard. It's nuissance to have to be able to confirm every
    save action.

    There doens't seem to be way to turn of this prompting.

SUGGESTION

    The logic of checking if file is write protedted or not does not seem
    to be reliable under Cygwin regarding network drives. The Permissions
    probably don't come through correctly for Emacs to examine them.

    A) Offer option to turn of confirmation
    B) or bypass write protection checks under Cygwin

TEST DATA

Here is an example under Cygwin Emacs:

    (file-attributes "/cygdrive/z/tmp/test-epackage.el")
    => (nil 1 4294967295.0 4294967295.0 (20194 11100) (20194 19792) (20194
    19792) 437 "-rwxr--r--" t (-1735557 1952988 . 8890) (30147 . 13405))

Under Cygwin Bash shell it looks like this:

    $ ls -la /cygdrive/z/tmp/test-epackage.el
    -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el

Note: the uid and gid information is not available from this non-domain
network drive.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/9/2011 1:23 PM, Jari Aalto wrote:
> Package: emacs
> Version: 23.3+1-4
> Severity: normal
>
> TEST CASE
>
>      - OS: Windows 7 64 bit
>      - Start Cygwin X server:
>        XWin :0 -unixkill -multiwindow
>      - Start Cygwin Emacs:
>        DISPLAY=:0 emacs-X11&
>      - C-x C-f any network drive file

Is there really a problem on *any* network drive, or is the issue that 
you have some particular file system on that drive for which Cygwin 
can't get reliable permission information?

I would think that you should try to get help on the Cygwin list before 
talking about making emacs bypass permission checks on Cygwin.  I don't 
use network drives myself, but I know that plenty of people do, and the 
Cygwin maintainers are very accommodating in trying to teach Cygwin to 
recognize problematic file systems.

And if that fails, can't you solve the problem by mounting your drive 
with the noacl option?

>      Emacs marks the file as read-only (%%) and asks every time a question
>      after pressing C-x C-s:
>
>          File<name here>  is write-protected; try to save anyway? (y or n)
>
> PROBLEM
>
>      The constant prompting "Y/N" makes writing to a network drive location
>      exessively hard. It's nuissance to have to be able to confirm every
>      save action.
>
>      There doens't seem to be way to turn of this prompting.
>
> SUGGESTION
>
>      The logic of checking if file is write protedted or not does not seem
>      to be reliable under Cygwin regarding network drives. The Permissions
>      probably don't come through correctly for Emacs to examine them.
>
>      A) Offer option to turn of confirmation
>      B) or bypass write protection checks under Cygwin
>
> TEST DATA
>
> Here is an example under Cygwin Emacs:
>
>      (file-attributes "/cygdrive/z/tmp/test-epackage.el")
>      =>  (nil 1 4294967295.0 4294967295.0 (20194 11100) (20194 19792) (20194
>      19792) 437 "-rwxr--r--" t (-1735557 1952988 . 8890) (30147 . 13405))
>
> Under Cygwin Bash shell it looks like this:
>
>      $ ls -la /cygdrive/z/tmp/test-epackage.el
>      -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el
>
> Note: the uid and gid information is not available from this non-domain
> network drive.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jaalto]

On 2011-12-09 15:33, Ken Brown wrote:
| 
| >Here is an example under Cygwin Emacs:
| >
| >     (file-attributes "/cygdrive/z/tmp/test-epackage.el")
| >     =>  (nil 1 4294967295.0 4294967295.0 (20194 11100) (20194 19792) (20194
| >     19792) 437 "-rwxr--r--" t (-1735557 1952988 . 8890) (30147 . 13405))
| >
| >Under Cygwin Bash shell it looks like this:
| >
| >     $ ls -la /cygdrive/z/tmp/test-epackage.el
| >     -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el
| >
|
| Is there really a problem on *any* network drive, or is the issue
| that you have some particular file system on that drive for which
| Cygwin can't get reliable permission information?

See above. The permissions from Cygwin shell look correct. It's the
UID, GID that don't translate back to windows, because this not a domain.

| I would think that you should try to get help on the Cygwin list
| before talking about making emacs bypass permission checks on
| Cygwin.  I don't use network drives myself, but I know that plenty
| of people do, and the Cygwin maintainers are very accommodating in
| trying to teach Cygwin to recognize problematic file systems.
| 
| And if that fails, can't you solve the problem by mounting your
| drive with the noacl option?

There are no problems under Cygwin. On Bash shell, all cp(1), mv(1)
and editors (nanoe, joe) write operations continue to work as usual.

For some reason Emacs thinks that all files are write protected.

The Disk drive has been mapped with Standard Windows "Map network
drive" feature.

Jari

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/10/2011 4:58 AM, jaalto wrote:
> On 2011-12-09 15:33, Ken Brown wrote:
> |
> |>Here is an example under Cygwin Emacs:
> |>
> |>      (file-attributes "/cygdrive/z/tmp/test-epackage.el")
> |>      =>   (nil 1 4294967295.0 4294967295.0 (20194 11100) (20194 19792) (20194
> |>      19792) 437 "-rwxr--r--" t (-1735557 1952988 . 8890) (30147 . 13405))
> |>
> |>Under Cygwin Bash shell it looks like this:
> |>
> |>      $ ls -la /cygdrive/z/tmp/test-epackage.el
> |>      -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el
> |>
> |
> | Is there really a problem on *any* network drive, or is the issue
> | that you have some particular file system on that drive for which
> | Cygwin can't get reliable permission information?
>
> See above. The permissions from Cygwin shell look correct. It's the
> UID, GID that don't translate back to windows, because this not a domain.
>
> | I would think that you should try to get help on the Cygwin list
> | before talking about making emacs bypass permission checks on
> | Cygwin.  I don't use network drives myself, but I know that plenty
> | of people do, and the Cygwin maintainers are very accommodating in
> | trying to teach Cygwin to recognize problematic file systems.
> |
> | And if that fails, can't you solve the problem by mounting your
> | drive with the noacl option?
>
> There are no problems under Cygwin. On Bash shell, all cp(1), mv(1)
> and editors (nanoe, joe) write operations continue to work as usual.
>
> For some reason Emacs thinks that all files are write protected.

emacs uses file-writable-p, which calls check_writable() (defined in 
fileio.c), which calls euidaccess().  That explains why emacs thinks the 
file is not writable when Cygwin can't determine the UID.  It would 
certainly be possible to make check_writable() use a different method of 
determining writability on Cygwin, as it already does on MSDOS.  But I 
still think it would be best to try to fix this in Cygwin first.

> The Disk drive has been mapped with Standard Windows "Map network
> drive" feature.

So why don't you ask on the Cygwin list whether access() and 
euidaccess() can be taught to give the "right" answer for files on such 
drives.  Or maybe the question is simply whether Cygwin can be taught to 
determine the correct UID.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-13 07:18, Ken Brown wrote:
| On 12/10/2011 4:58 AM, jaalto wrote:
| >On 2011-12-09 15:33, Ken Brown wrote:
| >|
| >|>Here is an example under Cygwin Emacs:
| >|>
| >|>      (file-attributes "/cygdrive/z/tmp/test-epackage.el")
| >|>      =>   (nil 1 4294967295.0 4294967295.0 (20194 11100) (20194 19792) (20194
| >|>      19792) 437 "-rwxr--r--" t (-1735557 1952988 . 8890) (30147 . 13405))
| >|>
| >|>Under Cygwin Bash shell it looks like this:
| >|>
| >|>      $ ls -la /cygdrive/z/tmp/test-epackage.el
| >|>      -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el
| >|>
| >|
| >| Is there really a problem on *any* network drive, or is the issue
| >| that you have some particular file system on that drive for which
| >| Cygwin can't get reliable permission information?
| >
| >See above. The permissions from Cygwin shell look correct. It's the
| >UID, GID that don't translate back to windows, because this not a domain.
>
| emacs uses file-writable-p, which calls check_writable() (defined in
| fileio.c), which calls euidaccess().  That explains why emacs thinks
| the file is not writable when Cygwin can't determine the UID.  It
| would certainly be possible to make check_writable() use a different
| method of determining writability on Cygwin, as it already does on
| MSDOS.  But I still think it would be best to try to fix this in
| Cygwin first.
|
| >The Disk drive has been mapped with Standard Windows "Map network
| >drive" feature.
| 
| So why don't you ask on the Cygwin list whether access() and
| euidaccess() can be taught to give the "right" answer for files on
| such drives.  Or maybe the question is simply whether Cygwin can be
| taught to determine the correct UID.

Sure, but because The network drive is not part of Windows Domain, I'm
afraid Cygwin has any means to determine what the correct UID or GID
would be are as they have no correspondence on the Windows side.

In any case, this is a big problem in daily use; especially because
the file system check cannot be ignored, bypassed or configured to
"just to go ahead and write without questions".

Jari

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Tue, 13 Dec 2011 16:00:42 +0200
> From: jari <jari.aalto@cante.net>
> Cc: 10257@debbugs.gnu.org
> 
> | So why don't you ask on the Cygwin list whether access() and
> | euidaccess() can be taught to give the "right" answer for files on
> | such drives.  Or maybe the question is simply whether Cygwin can be
> | taught to determine the correct UID.
> 
> Sure, but because The network drive is not part of Windows Domain, I'm
> afraid Cygwin has any means to determine what the correct UID or GID
> would be are as they have no correspondence on the Windows side.

??? As long as the network drive is mounted using Windows APIs (which
must be the case), the NT security features should be fully supported
for it.  That includes the user and group IDs of every file.  So why
does Cygwin's `stat' return 4294967295 (which AFAIU is a fancy way of
saying -1) for UID and GID of these files?

> In any case, this is a big problem in daily use; especially because
> the file system check cannot be ignored, bypassed or configured to
> "just to go ahead and write without questions".

We don't want to put some ad-hoc "solution" into Emacs just because it
is urgent for you.  We want to understand the problem, and in
particular figure out whether it is an Emacs problem or a problem with
the Cygwin implementation of some library function.  Only then it will
be possible to establish what is the best solution.

Ken repeatedly suggested that you ask on the Cygwin list about this.
I think this is a good idea, as people here (with the exception of
Ken) know very little about Cygwin internals.

In any case, if you don't wish to follow Ken's advice, but want to
solve this urgent problem, you have the sources, don't you?

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

I have a question about the emacs side of this.  I wonder what the 
rationale is for testing writability before trying to save the file, and 
then asking the user for confirmation in case the (unreliable) test for 
writability fails (*).

It might be reasonable to just assume that the user really wants to save 
the file; the worst thing that can happen is that the write fails.  Am I 
missing something?

Ken

(*) According to the documentation at

  http://www.kernel.org/doc/man-pages/online/pages/man3/euidaccess.3.html

euidaccess() and access () are not reliable for checking permissions. 
The advice there is to simply try the desired operation and check for 
errors.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Stefan Monnier]

> I have a question about the emacs side of this.  I wonder what the rationale
> is for testing writability before trying to save the file, and then asking
> the user for confirmation in case the (unreliable) test for writability
> fails (*).

Can you point us to the piece of code about which you're talking?
Ideally, show us a sample pseudo patch (even better if it compiles, even
better if it works) showing the kind of change you have in mind.


        Stefan

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/13/2011 2:27 PM, Stefan Monnier wrote:
>> I have a question about the emacs side of this.  I wonder what the rationale
>> is for testing writability before trying to save the file, and then asking
>> the user for confirmation in case the (unreliable) test for writability
>> fails (*).
>
> Can you point us to the piece of code about which you're talking?
> Ideally, show us a sample pseudo patch (even better if it compiles, even
> better if it works) showing the kind of change you have in mind.

The code I'm talking about is near the beginning of the definition of 
`basic-save-buffer-2' in files.el:

     (if (not (file-writable-p buffer-file-name))
	(let ((dir (file-name-directory buffer-file-name)))
	  (if (not (file-directory-p dir))
	      (if (file-exists-p dir)
		  (error "%s is not a directory" dir)
		(error "%s: no such directory" dir))
	    (if (not (file-exists-p buffer-file-name))
		(error "Directory %s write-protected" dir)
	      (if (yes-or-no-p
		   (format
		    "File %s is write-protected; try to save anyway? "
		    (file-name-nondirectory
		     buffer-file-name)))
		  (setq tempsetmodes t)
		(error "Attempt to save to a file which you aren't allowed to write"))))))

I'm not (yet) proposing a change.  I'm simply asking what the rationale 
is for calling `yes-or-no-p' and making the user confirm that s/he wants 
to try to save the file.  I don't see that any harm would come from just 
trying to do what the user asked for, without making him/her ask a 
second time.  If the file really is write-protected, there will be an error.

If you agree, then I guess I would propose the following patch (not yet 
tested):

=== modified file 'lisp/files.el'
--- lisp/files.el       2011-12-04 08:02:42 +0000
+++ lisp/files.el       2011-12-13 20:08:55 +0000
@@ -4456,13 +4456,7 @@
                 (error "%s: no such directory" dir))
             (if (not (file-exists-p buffer-file-name))
                 (error "Directory %s write-protected" dir)
-             (if (yes-or-no-p
-                  (format
-                   "File %s is write-protected; try to save anyway? "
-                   (file-name-nondirectory
-                    buffer-file-name)))
-                 (setq tempsetmodes t)
-               (error "Attempt to save to a file which you aren't 
allowed to write"))))))
+             (setq tempsetmodes t)))))
      (or buffer-backed-up
         (setq setmodes (backup-buffer)))
      (let* ((dir (file-name-directory buffer-file-name))


Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Stefan Monnier]

> The code I'm talking about is near the beginning of the definition of
> basic-save-buffer-2' in files.el:

Thanks.

> I'm not (yet) proposing a change.  I'm simply asking what the rationale is
> for calling `yes-or-no-p' and making the user confirm that s/he wants to try
> to save the file.

I'm not sure what was the intention, but I know that this code is
triggered in cases such as:
- running as root: write will always succeed.
- saving to a read-only file that you own: while `write' will fail,
  you can make it succeed by changing the access rights (which is what
  tempsetmodes is for).
- saving to a read-only file in a writable dir: write will fail, but
  you can make it succeed by calling unlink first [Not sure if this
  works in Emacs right now].
In all these cases, Emacs is able to write the file, but the read-only
bit expresses an intention not to modify the file so it makes sense to
ask for confirmation.

This said, the code you quote should never prevent you from saving
a file, it should only ask for confirmation (i.e. it might be annoying
but it shouldn't prevent you from getting your work done).

But other than for the "running as root" case, the above two cases could
replace the `file-writable-p' test with a `write-region' test:
file-writable-p is documented (via POSIX's documentation of `access') to
be an approximation, whereas `write-region' should reliably tell us
whether we can write to the file.

> I don't see that any harm would come from just trying to
> do what the user asked for, without making him/her ask a second time.

I'm not sure what second time you're thinking of.

> If you agree, then I guess I would propose the following patch (not yet
> tested):

Your patch would probably remove the ability to save to a read-only file.


        Stefan

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/13/2011 9:54 PM, Stefan Monnier wrote:
>> The code I'm talking about is near the beginning of the definition of
>> basic-save-buffer-2' in files.el:
>
> Thanks.
>
>> I'm not (yet) proposing a change.  I'm simply asking what the rationale is
>> for calling `yes-or-no-p' and making the user confirm that s/he wants to try
>> to save the file.
>
> I'm not sure what was the intention, but I know that this code is
> triggered in cases such as:
> - running as root: write will always succeed.
> - saving to a read-only file that you own: while `write' will fail,
>    you can make it succeed by changing the access rights (which is what
>    tempsetmodes is for).
> - saving to a read-only file in a writable dir: write will fail, but
>    you can make it succeed by calling unlink first [Not sure if this
>    works in Emacs right now].
> In all these cases, Emacs is able to write the file, but the read-only
> bit expresses an intention not to modify the file so it makes sense to
> ask for confirmation.

There's a fourth case, and that's what led to the present bug report (by 
Jari):
- saving to a file that is in fact writable, for which file-writable-p 
gives the wrong answer.

> This said, the code you quote should never prevent you from saving
> a file, it should only ask for confirmation (i.e. it might be annoying
> but it shouldn't prevent you from getting your work done).

Jari was annoyed to the point where he felt he couldn't get his work 
done.  He's in a situation where file-writable-p will consistently 
report that a file is not writable, but writing will in fact succeed.  I 
was trying to help him find a way to avoid having to repeatedly confirm 
that he wants to save.

> But other than for the "running as root" case, the above two cases could
> replace the `file-writable-p' test with a `write-region' test:
> file-writable-p is documented (via POSIX's documentation of `access') to
> be an approximation, whereas `write-region' should reliably tell us
> whether we can write to the file.

So that sounds like a solution to Jari's problem.  I'll leave it to him 
to propose a patch along those lines.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Jari Aalto]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

2011-12-14 05:27 Ken Brown <kbrown@cornell.edu>:
| On 12/13/2011 9:54 PM, Stefan Monnier wrote:
| >> The code I'm talking about is near the beginning of the definition of
| >> basic-save-buffer-2' in files.el:
| >
| > I'm not sure what was the intention, but I know that this code is
| > triggered in cases such as:
|   [snip]
|
| (... and) saving to a file that is in fact writable, for which
| file-writable-p gives the wrong answer.
| 
| > This said, the code you quote should never prevent you from saving
| > a file, it should only ask for confirmation (i.e. it might be annoying
| > but it shouldn't prevent you from getting your work done).

For occasional confirmation, this is acceptable. But in this case every
single save is prompted while I know I have a write access. The protective
prompting turned into nightmare.

I'm proposing following,
Jari

2011-12-14  Jari Aalto  <jari.aalto@cante.net>

        * files.el (basic-save-buffer-2): Add
        `save-buffer-read-only-confirm-flag' to control asking to a
        write-protected file.
        (save-buffer-read-only-confirm-flag): New user variable
        (bug#10257).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-user-variable-to-control-asking-to-a-write-prote.patch --]
[-- Type: text/x-diff, Size: 2519 bytes --]

From 5e1873b417fd5bc79a05339cb9d1e1aacb57164a Mon Sep 17 00:00:00 2001
From: Jari Aalto <jari.aalto@cante.net>
Date: Wed, 14 Dec 2011 10:00:38 +0200
Subject: [PATCH] Add user variable to control asking to a write-protected
 file.
Organization: Private
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

files.el (basic-save-buffer-2): Add `save-buffer-read-only-confirm-flag'
(save-buffer-read-only-confirm-flag): New user variable (bug#10257).

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
 lisp/files.el |   23 ++++++++++++++++-------
 1 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/lisp/files.el b/lisp/files.el
index 40b6e7d..52c11b7 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -4445,9 +4445,17 @@ Before and after saving the buffer, this function runs
       (setq buffer-file-coding-system-explicit
 	    (cons last-coding-system-used nil)))))
 
+;; See 2011-12-09 Emacs Bug#10257 for details
+(defvar save-buffer-read-only-confirm-flag t
+  "*If non-nil, do not ask writable confiramtion in `basic-save-buffer-2'.
+Useful e.g. under Cygwin where the returned read-only status of
+a file may not be accurate over Windows mapped network drives.")
+
 ;; This returns a value (MODES SELINUXCONTEXT BACKUPNAME), like backup-buffer.
 (defun basic-save-buffer-2 ()
   (let (tempsetmodes setmodes)
+    ;; Note: the file-writable-p checks
+    ;; UID, GID which are not necessarily correct e.g. under Cygwin.
     (if (not (file-writable-p buffer-file-name))
 	(let ((dir (file-name-directory buffer-file-name)))
 	  (if (not (file-directory-p dir))
@@ -4456,13 +4464,14 @@ Before and after saving the buffer, this function runs
 		(error "%s: no such directory" dir))
 	    (if (not (file-exists-p buffer-file-name))
 		(error "Directory %s write-protected" dir)
-	      (if (yes-or-no-p
-		   (format
-		    "File %s is write-protected; try to save anyway? "
-		    (file-name-nondirectory
-		     buffer-file-name)))
-		  (setq tempsetmodes t)
-		(error "Attempt to save to a file which you aren't allowed to write"))))))
+	      (if save-buffer-read-only-confirm-flag
+		  (if (yes-or-no-p
+		       (format
+			"File %s is write-protected; try to save anyway? "
+			(file-name-nondirectory
+			 buffer-file-name)))
+		      (setq tempsetmodes t)
+		    (error "Attempt to save to a file which you aren't allowed to write")))))))
     (or buffer-backed-up
 	(setq setmodes (backup-buffer)))
     (let* ((dir (file-name-directory buffer-file-name))
-- 
1.7.7.3

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> From: Jari Aalto <jari.aalto@cante.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii <eliz@gnu.org>,  10257@debbugs.gnu.org,  jari <jari.aalto@cante.net>
> Date: Wed, 14 Dec 2011 10:01:47 +0200
> 
> I'm proposing following,
> Jari
> 
> 2011-12-14  Jari Aalto  <jari.aalto@cante.net>
> 
>         * files.el (basic-save-buffer-2): Add
>         `save-buffer-read-only-confirm-flag' to control asking to a
>         write-protected file.
>         (save-buffer-read-only-confirm-flag): New user variable
>         (bug#10257).

Yuck!  Are we going to add a knob for every possible misconfiguration
of network filesystems and/or for every incompatibility in Posix
emulation layers on Windows?

Up till now, the way to deal with this was either to change the
generic code (where it was deemed to be deficient in the first place),
or ask the maintainers of the platform to fix that either in the
platform libraries or in platform-specific code in Emacs.  I think
that is the right way; adding a user option every time is not, IMNSHO.

If native Windows and even MS-DOS ports can DTRT with this, then how
come Cygwin cannot?

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 3:35 AM, Eli Zaretskii wrote:
>> From: Jari Aalto<jari.aalto@cante.net>
>> Cc: Stefan Monnier<monnier@iro.umontreal.ca>,  Eli Zaretskii<eliz@gnu.org>,  10257@debbugs.gnu.org,  jari<jari.aalto@cante.net>
>> Date: Wed, 14 Dec 2011 10:01:47 +0200
>>
>> I'm proposing following,
>> Jari
>>
>> 2011-12-14  Jari Aalto<jari.aalto@cante.net>
>>
>>          * files.el (basic-save-buffer-2): Add
>>          `save-buffer-read-only-confirm-flag' to control asking to a
>>          write-protected file.
>>          (save-buffer-read-only-confirm-flag): New user variable
>>          (bug#10257).
>
> Yuck!  Are we going to add a knob for every possible misconfiguration
> of network filesystems and/or for every incompatibility in Posix
> emulation layers on Windows?
>
> Up till now, the way to deal with this was either to change the
> generic code (where it was deemed to be deficient in the first place),
> or ask the maintainers of the platform to fix that either in the
> platform libraries or in platform-specific code in Emacs.  I think
> that is the right way; adding a user option every time is not, IMNSHO.
>
> If native Windows and even MS-DOS ports can DTRT with this, then how
> come Cygwin cannot?

The MS-DOS port uses system-specific code in `check_writable' (see 
fileio.c).  I don't know whether the native Windows port DTRT for Jari's 
network filesystem.  Jari, can you test this?

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 7:24 AM, Ken Brown wrote:
> On 12/14/2011 3:35 AM, Eli Zaretskii wrote:
>>> From: Jari Aalto<jari.aalto@cante.net>
>>> Cc: Stefan Monnier<monnier@iro.umontreal.ca>, Eli
>>> Zaretskii<eliz@gnu.org>, 10257@debbugs.gnu.org,
>>> jari<jari.aalto@cante.net>
>>> Date: Wed, 14 Dec 2011 10:01:47 +0200
>>>
>>> I'm proposing following,
>>> Jari
>>>
>>> 2011-12-14 Jari Aalto<jari.aalto@cante.net>
>>>
>>> * files.el (basic-save-buffer-2): Add
>>> `save-buffer-read-only-confirm-flag' to control asking to a
>>> write-protected file.
>>> (save-buffer-read-only-confirm-flag): New user variable
>>> (bug#10257).
>>
>> Yuck! Are we going to add a knob for every possible misconfiguration
>> of network filesystems and/or for every incompatibility in Posix
>> emulation layers on Windows?
>>
>> Up till now, the way to deal with this was either to change the
>> generic code (where it was deemed to be deficient in the first place),
>> or ask the maintainers of the platform to fix that either in the
>> platform libraries or in platform-specific code in Emacs. I think
>> that is the right way; adding a user option every time is not, IMNSHO.
>>
>> If native Windows and even MS-DOS ports can DTRT with this, then how
>> come Cygwin cannot?
>
> The MS-DOS port uses system-specific code in `check_writable' (see
> fileio.c). I don't know whether the native Windows port DTRT for Jari's
> network filesystem. Jari, can you test this?

Ignore my question.  I don't think it's relevant, nor do I think there's 
any need for Cygwin-specific code in emacs to deal with this.  As I 
understand it, this is a filesystem problem: Samba returns a fake SID to 
Windows, so Cygwin can't determine the correct uid/gid.  Jari, you were 
already told on the Cygwin list how to work around this problem.  Why 
not just do it?

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 07:55:07 -0500
> From: Ken Brown <kbrown@cornell.edu>
> CC: 10257@debbugs.gnu.org, Jari Aalto <jari.aalto@cante.net>
> 
> As I understand it, this is a filesystem problem: Samba returns a
> fake SID to Windows, so Cygwin can't determine the correct uid/gid.
> Jari, you were already told on the Cygwin list how to work around
> this problem.  Why not just do it?

Either that, or make euidaccess/check_writable return success in such
cases.  After all, it is well known that on Windows the equivalent of
euidaccess (AccessCheck and its ilk) is even more of an approximation
than on Posix, due to implicit access rights granted through
membership in multiple user groups.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 8:10 AM, Eli Zaretskii wrote:
>> Date: Wed, 14 Dec 2011 07:55:07 -0500
>> From: Ken Brown<kbrown@cornell.edu>
>> CC: 10257@debbugs.gnu.org, Jari Aalto<jari.aalto@cante.net>
>>
>> As I understand it, this is a filesystem problem: Samba returns a
>> fake SID to Windows, so Cygwin can't determine the correct uid/gid.
>> Jari, you were already told on the Cygwin list how to work around
>> this problem.  Why not just do it?
>
> Either that, or make euidaccess/check_writable return success in such
> cases.

I don't know how to determine what "such cases" are.  In the case at 
hand, Jari has a network filesystem that is configured in such a way 
that the uid/gid of a file can't be determined by standard system calls. 
  As explained on the Cygwin list, he can set up his /etc/passwd and 
/etc/group to work around this.  [He has to map the fake SID returned by 
Samba to a real one.]  If he doesn't want to do that, I think it would 
clearly be wrong for euidaccess to return success.

Maybe check_writable could be a little more lenient, but I'm not sure 
what the implications of that would be.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-14 09:19, Ken Brown wrote:
| >>As I understand it, this is a filesystem problem: Samba returns a
| >>fake SID to Windows, so Cygwin can't determine the correct uid/gid.
| >
| >Either that, or make euidaccess/check_writable return success in such
| >cases.
| 
| (...) /etc/passwd and /etc/group to work around this.  [He has to map the
| fake SID returned by Samba to a real one.]  If he doesn't want to do
| that (..)

I'm unable to get those values configured properly. I've rechecked
Corrinna's Cygwin-ML examples and compared them to my tries over and
over, and it still shows ???? for the UID part. GID succeed.

Jari

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 09:19:16 -0500
> From: Ken Brown <kbrown@cornell.edu>
> CC: 10257@debbugs.gnu.org, jari.aalto@cante.net
> 
> > Either that, or make euidaccess/check_writable return success in such
> > cases.
> 
> I don't know how to determine what "such cases" are.

"Such cases" are those where UID and GID are returned as -1 (I think),
see the original report where Jari shows the result of
file-attributes.

I believe Corinna also wrote something about the special SID values
returned in this case.  You could use these special values to detect
this situation and work around it.

> In the case at hand, Jari has a network filesystem that is
> configured in such a way that the uid/gid of a file can't be
> determined by standard system calls.  As explained on the Cygwin
> list, he can set up his /etc/passwd and /etc/group to work around
> this.  [He has to map the fake SID returned by Samba to a real one.]
> If he doesn't want to do that, I think it would clearly be wrong for
> euidaccess to return success.

My POV is that "such cases" are better solved inside euidaccess: it
doesn't make much sense to force the users to jump through the hoops
when it is known that the library is unable to determine something
reliably, in this case the uid/gid values.  In such cases, the library
should do whatever will punish users the least.

But that's me; if the Cygwin maintainers disagree and will not modify
euidaccess, then you could try doing the equivalent of this in Emacs.

> Maybe check_writable could be a little more lenient, but I'm not sure 
> what the implications of that would be.

The file is already writable in this case, so how bad can this become?

The trick is not to be more lenient in all the cases, only in these
problematic ones.  Then you can never do worse than we do now.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 12:30 PM, Eli Zaretskii wrote:
> "Such cases" are those where UID and GID are returned as -1 (I think),
> see the original report where Jari shows the result of
> file-attributes.

OK, I could certainly change check_writable to return success if 
euidaccess returns failure and UID and GID are both -1.  I'll make a 
patch when I get a chance and let Jari test it.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 12:57 PM, Ken Brown wrote:
> On 12/14/2011 12:30 PM, Eli Zaretskii wrote:
>> "Such cases" are those where UID and GID are returned as -1 (I think),
>> see the original report where Jari shows the result of
>> file-attributes.
>
> OK, I could certainly change check_writable to return success if
> euidaccess returns failure and UID and GID are both -1. I'll make a
> patch when I get a chance and let Jari test it.

How does the following patch look?

=== modified file 'src/fileio.c'
--- src/fileio.c	2011-12-05 08:55:25 +0000
+++ src/fileio.c	2011-12-15 02:17:01 +0000
@@ -2416,15 +2416,27 @@
    return (st.st_mode & S_IWRITE || S_ISDIR (st.st_mode));
  #else /* not MSDOS */
  #ifdef HAVE_EUIDACCESS
-  return (euidaccess (filename, 2) >= 0);
-#else
+  int res = (euidaccess (filename, 2) >= 0);
+#ifdef CYGWIN
+  /* euidaccess may have returned failure because Cygwin couldn't
+     determine the file's UID and GID; if so, we return success. */
+  if (!res)
+    {
+      struct stat st;
+      if (stat (filename, &st) < 0)
+        return 0;
+      res = (st.st_uid == -1 && st.st_gid == -1);
+    }
+#endif /* CYGWIN */
+  return res;
+#else /* not HAVE_EUIDACCESS */
    /* Access isn't quite right because it uses the real uid
       and we really want to test with the effective uid.
       But Unix doesn't give us a right way to do it.
       Opening with O_WRONLY could work for an ordinary file,
       but would lose for directories.  */
    return (access (filename, 2) >= 0);
-#endif
+#endif /* not HAVE_EUIDACCESS */
  #endif /* not MSDOS */
  }

Jari, can you test it and see if it solves your problem?

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 9:43 PM, Ken Brown wrote:
> On 12/14/2011 12:57 PM, Ken Brown wrote:
>> On 12/14/2011 12:30 PM, Eli Zaretskii wrote:
>>> "Such cases" are those where UID and GID are returned as -1 (I think),
>>> see the original report where Jari shows the result of
>>> file-attributes.
>>
>> OK, I could certainly change check_writable to return success if
>> euidaccess returns failure and UID and GID are both -1. I'll make a
>> patch when I get a chance and let Jari test it.
>
> How does the following patch look?
>
> === modified file 'src/fileio.c'
> --- src/fileio.c 2011-12-05 08:55:25 +0000
> +++ src/fileio.c 2011-12-15 02:17:01 +0000
> @@ -2416,15 +2416,27 @@
> return (st.st_mode & S_IWRITE || S_ISDIR (st.st_mode));
> #else /* not MSDOS */
> #ifdef HAVE_EUIDACCESS
> - return (euidaccess (filename, 2) >= 0);
> -#else
> + int res = (euidaccess (filename, 2) >= 0);
> +#ifdef CYGWIN
> + /* euidaccess may have returned failure because Cygwin couldn't
> + determine the file's UID and GID; if so, we return success. */
> + if (!res)
> + {
> + struct stat st;
> + if (stat (filename, &st) < 0)
> + return 0;
> + res = (st.st_uid == -1 && st.st_gid == -1);
> + }
> +#endif /* CYGWIN */
> + return res;
> +#else /* not HAVE_EUIDACCESS */
> /* Access isn't quite right because it uses the real uid
> and we really want to test with the effective uid.
> But Unix doesn't give us a right way to do it.
> Opening with O_WRONLY could work for an ordinary file,
> but would lose for directories. */
> return (access (filename, 2) >= 0);
> -#endif
> +#endif /* not HAVE_EUIDACCESS */
> #endif /* not MSDOS */
> }

Sorry, this isn't quite right.  I think it's too lenient.  As long as 
I've called stat, I should at least check that stat shows the file to be 
writable, as in the MSDOS port.

I'll send a revised patch.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 9:53 PM, Ken Brown wrote:
> Sorry, this isn't quite right. I think it's too lenient. As long as I've
> called stat, I should at least check that stat shows the file to be
> writable, as in the MSDOS port.
>
> I'll send a revised patch.

Never mind.  It's probably not worth the trouble to check further if we 
don't even know the file's owner or group.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 21:43:07 -0500
> From: Ken Brown <kbrown@cornell.edu>
> CC: 10257@debbugs.gnu.org, jari.aalto@cante.net
> 
> On 12/14/2011 12:57 PM, Ken Brown wrote:
> > On 12/14/2011 12:30 PM, Eli Zaretskii wrote:
> >> "Such cases" are those where UID and GID are returned as -1 (I think),
> >> see the original report where Jari shows the result of
> >> file-attributes.
> >
> > OK, I could certainly change check_writable to return success if
> > euidaccess returns failure and UID and GID are both -1. I'll make a
> > patch when I get a chance and let Jari test it.
> 
> How does the following patch look?

Looks fine to me, if it does the job.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 11:04 PM, Eli Zaretskii wrote:
>> How does the following patch look?
>
> Looks fine to me, if it does the job.

Thanks.

It works for me, but I'd like Jari to confirm.  I was able to test it 
because there are some files on my system that are owned by the 
TrustedInstaller virtual user.  Cygwin currently doesn't create 
/etc/passwd and /etc/group entries for TrustedInstaller, so its files 
show up with UID and GID equal to -1.

By the way, the check_executable function calls euidaccess in the same 
way as check_writable, but I don't think I want to change that one to be 
more permissive unless there's a good reason to do so.  It seems to be 
used mainly to check for standard programs, which I hope aren't going to 
be found on a network share configured in such a way that the UID/GID 
can't be determined.

Thanks, as always, for being so helpful.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/15/2011 9:42 AM, Ken Brown wrote:
> On 12/14/2011 11:04 PM, Eli Zaretskii wrote:
>>> How does the following patch look?
>>
>> Looks fine to me, if it does the job.
>
> Thanks.
>
> It works for me, but I'd like Jari to confirm.

Jari has confirmed in private email that it works, but he has proposed 
making it slightly more permissive and having check_writable return 
success if either UID or GID is -1.  The rationale is the same as 
before:  If euidaccess returns failure but either UID or GID is -1, then 
the result of euidaccess is unreliable.  The revised patch is below.

Eli, do you see any problem with this extra permissiveness?

Stefan, is it OK to apply the patch to the trunk, or would you rather I 
wait for 24.2?

Ken

=== modified file 'src/fileio.c'
--- src/fileio.c        2011-12-05 08:55:25 +0000
+++ src/fileio.c        2011-12-16 19:32:23 +0000
@@ -2416,15 +2416,27 @@
    return (st.st_mode & S_IWRITE || S_ISDIR (st.st_mode));
  #else /* not MSDOS */
  #ifdef HAVE_EUIDACCESS
-  return (euidaccess (filename, 2) >= 0);
-#else
+  int res = (euidaccess (filename, 2) >= 0);
+#ifdef CYGWIN
+  /* euidaccess may have returned failure because Cygwin couldn't
+     determine the file's UID or GID; if so, we return success. */
+  if (!res)
+    {
+      struct stat st;
+      if (stat (filename, &st) < 0)
+        return 0;
+      res = (st.st_uid == -1 || st.st_gid == -1);
+    }
+#endif /* CYGWIN */
+  return res;
+#else /* not HAVE_EUIDACCESS */
    /* Access isn't quite right because it uses the real uid
       and we really want to test with the effective uid.
       But Unix doesn't give us a right way to do it.
       Opening with O_WRONLY could work for an ordinary file,
       but would lose for directories.  */
    return (access (filename, 2) >= 0);
-#endif
+#endif /* not HAVE_EUIDACCESS */
  #endif /* not MSDOS */
  }

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Fri, 16 Dec 2011 14:37:30 -0500
> From: Ken Brown <kbrown@cornell.edu>
> CC: 10257@debbugs.gnu.org, jari.aalto@cante.net,
>         Stefan Monnier <monnier@IRO.UMontreal.CA>
> 
> Jari has confirmed in private email that it works, but he has proposed 
> making it slightly more permissive and having check_writable return 
> success if either UID or GID is -1.  The rationale is the same as 
> before:  If euidaccess returns failure but either UID or GID is -1, then 
> the result of euidaccess is unreliable.  The revised patch is below.
> 
> Eli, do you see any problem with this extra permissiveness?

No, I was thinking along the same lines.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Stefan Monnier]

> Stefan, is it OK to apply the patch to the trunk, or would you rather I wait
> for 24.2?

Sounds fine,


        Stefan

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

Version: 24.0.93

I've applied the patch and am closing the bug.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-14 07:55, Ken Brown wrote:
| ...
| >> [Eli] or ask the maintainers of the platform to fix that either in the
| >> platform libraries or in platform-specific code in Emacs. I think
| >> that is the right way; adding a user option every time is not, IMNSHO.
| >>
| >> If native Windows and even MS-DOS ports can DTRT with this, then how
| >> come Cygwin cannot?

To recap:

- Cygwin can, but it needs special setup. This setup is not trivial:
  if you intend to use same Windows Mapped Network Drive. If you use
  mount(1), you lose Windows File Manager Integration because paths
  are no longer the same.

- Emacs can't rely on UID, GID on Cygwin to be correct. 

| >The MS-DOS port uses system-specific code in `check_writable' (see
| >fileio.c). I don't know whether the native Windows port DTRT for Jari's
| >network filesystem. Jari, can you test this?

Yes, Windows NT EMacs port works fine. No problems

- File on remote drive are not marked read-only
- File on remote drive are written without asking.

| As I understand it, this is a filesystem problem: Samba returns a
| fake SID to Windows, so Cygwin can't determine the correct uid/gid.

Yes.

| Jari, you were already told on the Cygwin list how to work around
| this problem.  Why not just do it?

It's too complex, and doesn't work with multiple Samaba severs that
would use all different GID, UIDs for the same user name, and I cannot
get right UIDs and GIDs installed ... too many issues.

I can work just fine under Cygwin without these GID, UIDs set. But I
can't use Emacs effectively.

I would expect there to be at least an option to control these
pre-emptive confirmation questions. Without any control, the situation
is a nightmare.

Compare:

      confirm-kill-emacs
      dired-no-confirm
      message-kill-buffer-on-exit
      vc-suppress-confirm
      ...

Jari

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/14/2011 9:15 AM, jari wrote:
> Yes, Windows NT EMacs port works fine. No problems
>
> - File on remote drive are not marked read-only
> - File on remote drive are written without asking.

So can you look into how the native Windows port implements 
check_writable?  Maybe we can do something similar on Cygwin.

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-14 09:29, Ken Brown wrote:
| On 12/14/2011 9:15 AM, jari wrote:
| >Yes, Windows NT EMacs port works fine. No problems
| >
| >- File on remote drive are not marked read-only
| >- File on remote drive are written without asking.
| 
| So can you look into how the native Windows port implements
| check_writable?  Maybe we can do something similar on Cygwin.

I only have the *.exe

Jari

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 09:29:47 -0500
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 10257@debbugs.gnu.org
> 
> So can you look into how the native Windows port implements 
> check_writable?

It calls `access', whose implementation is in w32.c:sys_access.  It
mostly calls GetFileAttributes and that's it.  If you want to check NT
security ACLs on Cygwin, then what the native build does will not be
good enough for you.  But you can perhaps fall back on that if the UID
and GID are bogus (see my other mail).

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Richard Stallman]

    I have a question about the emacs side of this.  I wonder what the 
    rationale is for testing writability before trying to save the file, and 
    then asking the user for confirmation in case the (unreliable) test for 
    writability fails (*).

I think the reason for the fallible first test is to avoid things that
are done (to backup files, for instance) before trying to write the
file.  It is good to avoid them if the write would fail anyway.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-13 09:43, Eli Zaretskii wrote:
| > | So why don't you ask on the Cygwin list whether access() and
| > | euidaccess() can be taught to give the "right" answer for files on
| > | such drives.  Or maybe the question is simply whether Cygwin can be
| > | taught to determine the correct UID.
| > 
| > Sure, but because The network drive is not part of Windows Domain, I'm
| > afraid Cygwin has any means to determine what the correct UID or GID
| > would be are as they have no correspondence on the Windows side.
| 
| ??? As long as the network drive is mounted using Windows APIs (which
| must be the case), the NT security features should be fully supported
| for it.  That includes the user and group IDs of every file.  So why
| does Cygwin's `stat' return 4294967295 (which AFAIU is a fancy way of
| saying -1) for UID and GID of these files?

Response from Cygwin list:

    >     $ ls -la /cygdrive/z/tmp/test-epackage.el
    >     -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el

    It's not a bug.

    If you use winbind and the user accounts are correctly mapped to
    Windows accounts, then you would see the Cygwin UIDs/GIDs
    correspoding to the SID of the AD user account.

    If you don't do that, there's only an invisible mapping from the
    Windows SID to the Unix uid/gid.  The actual UNIX account has not
    the same mapping back to the Windows SID.  Instead, the SID
    returned from Samba to Windows is a fake SID S-1-22-1-UnixUID or
    S-1-22-2-UnixGID.  (..)

The rest goes into details for setting 1:1 UID, GID mapping.

Still,

     - The mapped drive can be written to without any extra 1:1 GUID,UID
       configuration.
     - Under Cygwin, should Emacs rely on unreliable[*] UID, GID?
     - Is there need for this extra prompt? The protective
       nature turned into nightmare.

Much better would be to give control back to the user:

  (setq write-file-interactive-confirmation-flag nil)

This doesn't affect Emacs's ability to signal an error on write
failure.

Jari

[*] Which depend on specific environment and settings user has. The
1:1 setting gets interesting for N servers that may have different
UID, GID settings for the same user names; as they may not all be part
of the same domain.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Ken Brown]

On 12/13/2011 11:26 AM, jari wrote:
> Response from Cygwin list:
>
>      >      $ ls -la /cygdrive/z/tmp/test-epackage.el
>      >      -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el
>
>      It's not a bug.
>
>      If you use winbind and the user accounts are correctly mapped to
>      Windows accounts, then you would see the Cygwin UIDs/GIDs
>      correspoding to the SID of the AD user account.
>
>      If you don't do that, there's only an invisible mapping from the
>      Windows SID to the Unix uid/gid.  The actual UNIX account has not
>      the same mapping back to the Windows SID.  Instead, the SID
>      returned from Samba to Windows is a fake SID S-1-22-1-UnixUID or
>      S-1-22-2-UnixGID.  (..)
>
> The rest goes into details for setting 1:1 UID, GID mapping.

You omitted the part of the response that says, "The easiest way to 
workaround this issue is to mount the share with the noacl mount 
option".  I also suggested this in my first response to your report. 
Does this fail to work for some reason?

Ken

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-13 11:52, Ken Brown wrote:
| On 12/13/2011 11:26 AM, jari wrote:
| >Response from Cygwin list:
| >
| >     >      $ ls -la /cygdrive/z/tmp/test-epackage.el
| >     >      -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el
| >
| >     It's not a bug.
| >
| >     If you use winbind and the user accounts are correctly mapped to
| >     Windows accounts, then you would see the Cygwin UIDs/GIDs
| >     correspoding to the SID of the AD user account.
| >
| >     If you don't do that, there's only an invisible mapping from the
| >     Windows SID to the Unix uid/gid.  The actual UNIX account has not
| >     the same mapping back to the Windows SID.  Instead, the SID
| >     returned from Samba to Windows is a fake SID S-1-22-1-UnixUID or
| >     S-1-22-2-UnixGID.  (..)
| >
| >The rest goes into details for setting 1:1 UID, GID mapping.
| 
| You omitted the part of the response that says, "The easiest way to
| workaround this issue is to mount the share with the noacl mount
| option".
| Does this fail to work for some reason?

That would create a new "Cygwin mount". Different path altogether than
what is already in use; mapped by the Windows.

     In Windows: Z:\
     In Cygwin : /cygdrive/z

All paths would change if I would Cygwin mount(1) "//server/login
/mnt/login ..."

    /mnt/login   <!=!>  /cygdrive/z

That would create problems all over the place that now assume certain
locations. Not to mention losing ability to copy/paste paths from
Windows File Exporer to Cygwin[*]

Jari

[*] Cygwin accepts drive letter syntax in single quotes: 'z:\'
See also cygoath(1).

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Tue, 13 Dec 2011 18:26:28 +0200
> From: jari <jari.aalto@cante.net>
> Cc: kbrown@cornell.edu, 10257@debbugs.gnu.org
> 
>      - The mapped drive can be written to without any extra 1:1 GUID,UID
>        configuration.
>      - Under Cygwin, should Emacs rely on unreliable[*] UID, GID?
>      - Is there need for this extra prompt? The protective
>        nature turned into nightmare.
> 
> Much better would be to give control back to the user:
> 
>   (setq write-file-interactive-confirmation-flag nil)
> 
> This doesn't affect Emacs's ability to signal an error on write
> failure.

Emacs assumes Posix-compliant APIs wrt UID/GID/EUID.  Platforms that
don't comply with the Posix semantics of these APIs should either
(a) become more compliant, or (b) modify the Emacs sources with
platform-specific code or #ifdef's to work around the lack of
compliance.  (Emacs maintainers generally prefer the former
possibility, for obvious reasons.)  All the other platforms do one
or the other; why should Cygwin be different? why should we change
long-standing Emacs code because one platform turns out to be non-
compliant, and the user refuses to work around the problem by
configuring his system in a slightly different way?

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[jari]

On 2011-12-13 19:48, Eli Zaretskii wrote:
| > Date: Tue, 13 Dec 2011 18:26:28 +0200
| > From: jari <jari.aalto@cante.net>
| > Cc: kbrown@cornell.edu, 10257@debbugs.gnu.org
| > 
| >      - The mapped drive can be written to without any extra 1:1 GUID,UID
| >        configuration.
| >      - Under Cygwin, should Emacs rely on unreliable[*] UID, GID?
| >      - Is there need for this extra prompt? The protective
| >        nature turned into nightmare.
| > 
| > Much better would be to give control back to the user:
| > 
| >   (setq write-file-interactive-confirmation-flag nil)
| > 
| > This doesn't affect Emacs's ability to signal an error on write
| > failure.
| 
| Emacs assumes Posix-compliant APIs wrt UID/GID/EUID.  Platforms that
| don't comply with the Posix semantics of these APIs should either
| (a) become more compliant, or (b) modify the Emacs sources with
| platform-specific code or #ifdef's to work around the lack of
| compliance.  (Emacs maintainers generally prefer the former
| possibility, for obvious reasons.)  All the other platforms do one
| or the other; why should Cygwin be different? why should we change
| long-standing Emacs code because one platform turns out to be non-
| compliant, and the user refuses to work around the problem by
| configuring his system in a slightly different way?

The proposed chnage, by letting the use to control the
prompting/checking behavior, would solve the issue.

As far as I can tell, it wouldn't break anything.

User already has a write access to the device.

Emacs just doesn't know / guesses wrong / environment is complex /
possibly uses wrong methodology (see Ken's notes about using uid, gid
for write access check).

So why not let user to help it to know via variable?

Jari

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Eli Zaretskii]

> Date: Tue, 13 Dec 2011 20:05:47 +0200
> From: jari <jari.aalto@cante.net>
> Cc: kbrown@cornell.edu, 10257@debbugs.gnu.org
> 
> User already has a write access to the device.
> 
> Emacs just doesn't know / guesses wrong / environment is complex /

If Cygwin's implementation of the Posix APIs were compliant, it would
know/guess correctly.

> possibly uses wrong methodology (see Ken's notes about using uid, gid
> for write access check).

Let's see where the discussion of Ken's questions leads us.  Only then
we will be able to conclude whether the current methodology is wrong
or not.

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> Sure, but because The network drive is not part of Windows Domain, I'm
>> afraid Cygwin has any means to determine what the correct UID or GID
>> would be are as they have no correspondence on the Windows side.
>
> ??? As long as the network drive is mounted using Windows APIs (which
> must be the case), the NT security features should be fully supported
> for it.

If the two computers are not members of the same domain, they know
nothing about each others users and groups.