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

[jaalto <jari.aalto@cante.net>]

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