From: Ken Brown <kbrown@cornell.edu>
To: jaalto <jari.aalto@cante.net>
Cc: 10257@debbugs.gnu.org
Subject: bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)
Date: Tue, 13 Dec 2011 07:18:56 -0500 [thread overview]
Message-ID: <4EE742B0.1080703@cornell.edu> (raw)
In-Reply-To: <20111210095858.GA19881@cante.cante.net>
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
next prev parent reply other threads:[~2011-12-13 12:18 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 18:23 bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive) Jari Aalto
2011-12-09 20:33 ` Ken Brown
2011-12-10 9:58 ` jaalto
2011-12-13 12:18 ` Ken Brown [this message]
2011-12-13 14:00 ` jari
2011-12-13 14:43 ` Eli Zaretskii
2011-12-13 15:12 ` Ken Brown
2011-12-13 19:27 ` Stefan Monnier
2011-12-13 20:16 ` Ken Brown
2011-12-14 2:54 ` Stefan Monnier
2011-12-14 3:27 ` Ken Brown
2011-12-14 8:01 ` Jari Aalto
2011-12-14 8:35 ` Eli Zaretskii
2011-12-14 12:24 ` Ken Brown
2011-12-14 12:55 ` Ken Brown
2011-12-14 13:10 ` Eli Zaretskii
2011-12-14 14:19 ` Ken Brown
2011-12-14 14:47 ` jari
2011-12-14 17:30 ` Eli Zaretskii
2011-12-14 17:57 ` Ken Brown
2011-12-15 2:43 ` Ken Brown
2011-12-15 2:53 ` Ken Brown
2011-12-15 3:19 ` Ken Brown
2011-12-15 4:04 ` Eli Zaretskii
2011-12-15 14:42 ` Ken Brown
2011-12-16 19:37 ` Ken Brown
2011-12-16 19:46 ` Eli Zaretskii
2011-12-16 23:15 ` Stefan Monnier
2011-12-17 17:08 ` Ken Brown
2011-12-14 14:15 ` jari
2011-12-14 14:29 ` Ken Brown
2011-12-14 14:43 ` jari
2011-12-14 17:21 ` Eli Zaretskii
2011-12-14 17:23 ` Richard Stallman
2011-12-13 16:26 ` jari
2011-12-13 16:52 ` Ken Brown
2011-12-13 17:48 ` jari
2011-12-13 17:48 ` Eli Zaretskii
2011-12-13 18:05 ` jari
2011-12-13 18:36 ` Eli Zaretskii
2011-12-15 14:44 ` Jason Rumney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE742B0.1080703@cornell.edu \
--to=kbrown@cornell.edu \
--cc=10257@debbugs.gnu.org \
--cc=jari.aalto@cante.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.