From: Will Parsons <varro@nodomain.invalid>
To: help-gnu-emacs@gnu.org
Subject: Re: mismatch between what Emacs considers read-only and file permissions
Date: 4 Feb 2015 19:53:33 GMT [thread overview]
Message-ID: <slrnmd4u5s.32r.varro@anukis.local> (raw)
In-Reply-To: mailman.19279.1423076671.1147.help-gnu-emacs@gnu.org
Eli Zaretskii wrote:
>> From: Will Parsons <varro@nodomain.invalid>
>> Date: 4 Feb 2015 17:12:52 GMT
>>
>> How does Emacs determine whether to mark a buffer read-only when
>> visiting a file that is writable?
>
> By looking at the file permission bits.
>
>> 1) Under Windows
>>
>> I make heavy use of the Cygwin environment under Windows, but usually
>> use the native Windows Emacs. I've never bothered to track down the
>> exact circumstances, but assume that Cygwin is setting file
>> permissions in a way that confuses native Emacs.
>
> Cygwin attempts to emulate Posix user/group/other permission bits by
> manipulating Windows NT security attributes. The way it does that
> will only work as you'd expect when those attributes are tested by
> Cygwin programs. Native Windows build of Emacs, OTOH, not only doesn't
> support the Cygwin fiddling with the NTSec features, it doesn't even
> look at those attributes when it checks files for accessibility;
> instead, it probes only the read-only bit (which is not affected by
> NTSec).
>
> My advice is not to mix Cygwin programs with native Emacs on Windows.
> Good native ports of Unix and GNU software to Windows are available,
> and you are advised to use them instead, if you don't want to deal
> with these incompatibilities.
I've been using Cywin for over a decade and find it far too useful to
live without. As I had stated, I'm perfectly happy to deal the
incompatibilities simply by changing the read-only attribute on the
buffer when needed.
My real question is the second circumstance, where a file with the
Unix write bit set is marked read-only by Emacs. Since it only occurs
when I log in directly as root in console mode (which I don't do that
often), I can live with that too, using the same method. By *why*
does it happen?
--
Will
next prev parent reply other threads:[~2015-02-04 19:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 17:12 mismatch between what Emacs considers read-only and file permissions Will Parsons
2015-02-04 19:04 ` Eli Zaretskii
[not found] ` <mailman.19279.1423076671.1147.help-gnu-emacs@gnu.org>
2015-02-04 19:53 ` Will Parsons [this message]
2015-02-04 20:00 ` Eli Zaretskii
[not found] ` <mailman.19282.1423080028.1147.help-gnu-emacs@gnu.org>
2015-02-04 20:19 ` Will Parsons
2015-02-05 13:24 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=slrnmd4u5s.32r.varro@anukis.local \
--to=varro@nodomain.invalid \
--cc=gyliamos@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).