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