[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10257: 23.3.1 Cygwin: network drives - file is write protected (fals

From: jari
Subject: bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)
Date: Tue, 13 Dec 2011 18:26:28 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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 

    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.


     - The mapped drive can be written to without any extra 1:1 GUID,UID
     - 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


[*] 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]