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

Previous Next

Full log

View this message in rfc822 format

From: jari <jari.aalto <at> cante.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10257 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)
Date: Tue, 13 Dec 2011 18:26:28 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.