bug#22795: 25.0.91; Can't write read only file on w32

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

When a file is read only on w32 platform I used to be able to write a
file by toggling the buffer's read-only-mode state and answering yes
to this question "File memo is write-protected; try to save anyway?
(yes or no)" but now the writing fails by an error message "Opening
output file: Permission denied, c:/d/ota/memo" It still works on Linux
platform.  Is this a new feature/policy on w32 platform or a bug?  It
is certainly inconvenient.

-Tak




In GNU Emacs 25.0.91.2 (i686-pc-mingw32)
 of 2016-02-17 built on TAK-SVZ131190X
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/c/emacs/emacs-25.0.91
 --enable-locallisppath=/c/emacs/site-lisp'

Configured features:
SOUND NOTIFY ACL TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: euc-jp-unix

Major mode: Summary

Minor modes in effect:
  auto-image-file-mode: t
  recentf-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t

Recent messages:
Checking 70 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/erc...
Checking 34 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/emulation...
Checking 168 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/emacs-lisp...
Checking 24 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/cedet...
Checking 57 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/calendar...
Checking 87 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/calc...
Checking 122 files in c:/emacs/emacs-25.0.91/share/emacs/25.0.91/lisp/obsolete...
Checking for load-path shadows...done
scroll-one-line-down: Beginning of buffer [16 times]
Auto-saving...done
scroll-one-line-down: Beginning of buffer [12 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired-x dired format-spec rfc822
mml mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mail-utils dabbrev rect flyspell ispell sdicf-client stem sdicf sdic qp
browse-url character-fold misearch multi-isearch bookmark pp
network-stream nsm starttls tls gnutls mew-varsx ffap url-parse
auth-source cl-seq eieio eieio-core cl-macs gv gnus-util mm-util
help-fns mail-prsvr url-vars wwtime file-templates ruler-mode time-stamp
eudcb-ldap ldap password-cache eudc eudc-options-file cus-edit cus-start
cus-load eudc-vars edebug jka-compr compile image-file gud pcvs vc-cvs
pcvs-parse pcvs-info pcvs-defs easy-mmode pcvs-util ewoc recentf
tree-widget wid-edit byte-opt bytecomp byte-compile cl-extra help-mode
cl-loaddefs pcase cl-lib cconv mew-auth mew-config mew-imap2 mew-imap
mew-nntp2 mew-nntp mew-pop mew-smtp mew-ssl mew-ssh mew-net
mew-highlight mew-sort mew-fib mew-ext ange-ftp comint ansi-color ring
mew-refile mew-demo mew-attach mew-draft mew-message mew-thread
mew-virtual mew-summary4 mew-summary3 mew-summary2 mew-summary
mew-search mew-pick mew-passwd mew-scan mew-syntax mew-bq mew-smime
mew-pgp mew-header mew-exec mew-mark mew-mime mew-win32 mew-edit
mew-decode mew-encode mew-cache mew-minibuf mew-complete mew-addrbook
mew-local mew-vars3 mew-vars2 mew-vars mew-env mew-lang-jp mew-mule3
mew-mule mew-gemacs mew-key mew-func mew-blvs mew-const mew kkc
ja-dic-utl japan-util advice thingatpt time cal-china lunar solar
cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs appt
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs finder-inf
w3-autoloads package easymenu epg-config time-date mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 421738 40180)
 (symbols 32 35267 0)
 (miscs 32 389 1024)
 (strings 16 84070 27755)
 (string-bytes 1 2070737)
 (vectors 8 31268)
 (vector-slots 4 1554396 32522)
 (floats 8 796 528)
 (intervals 28 7055 1406)
 (buffers 516 38))

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Wed, 24 Feb 2016 08:44:02 -0800
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> When a file is read only on w32 platform I used to be able to write a
> file by toggling the buffer's read-only-mode state and answering yes
> to this question "File memo is write-protected; try to save anyway?
> (yes or no)" but now the writing fails by an error message "Opening
> output file: Permission denied, c:/d/ota/memo"

I cannot reproduce this, neither with today's emacs-25 nor with the
last pretest of 25.1.  If I answer yes to that question, the file is
saved without any errors.

How did you make the file read-only?  (I used a Windows port of
'chmod' and the 'attrib' command.)

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Wed, 24 Feb 2016 21:09:57 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 24 Feb 2016 08:44:02 -0800
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > When a file is read only on w32 platform I used to be able to write a
> > file by toggling the buffer's read-only-mode state and answering yes
> > to this question "File memo is write-protected; try to save anyway?
> > (yes or no)" but now the writing fails by an error message "Opening
> > output file: Permission denied, c:/d/ota/memo"
> 
> I cannot reproduce this, neither with today's emacs-25 nor with the
> last pretest of 25.1.  If I answer yes to that question, the file is
> saved without any errors.
> 
> How did you make the file read-only?  (I used a Windows port of
> 'chmod' and the 'attrib' command.)

I used Windows Explorer's GUI to open the file property window and
placed a check on Read-only attribute.  I am using mingw to build the
emacs.  I just tried with 24.5 and it works but not on 25.0.90/91.
They are all build by the same mingw.

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Wed, 24 Feb 2016 13:57:49 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> Wed, 24 Feb 2016 21:09:57 +0200: Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > Date: Wed, 24 Feb 2016 08:44:02 -0800
> > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > 
> > > When a file is read only on w32 platform I used to be able to write a
> > > file by toggling the buffer's read-only-mode state and answering yes
> > > to this question "File memo is write-protected; try to save anyway?
> > > (yes or no)" but now the writing fails by an error message "Opening
> > > output file: Permission denied, c:/d/ota/memo"
> > 
> > I cannot reproduce this, neither with today's emacs-25 nor with the
> > last pretest of 25.1.  If I answer yes to that question, the file is
> > saved without any errors.
> > 
> > How did you make the file read-only?  (I used a Windows port of
> > 'chmod' and the 'attrib' command.)
> 
> I used Windows Explorer's GUI to open the file property window and
> placed a check on Read-only attribute.  I am using mingw to build the
> emacs.  I just tried with 24.5 and it works but not on 25.0.90/91.
> They are all build by the same mingw.

This doesn't happen for me even if I use the Explorer.

There's some other factor at work here.  Does this happen with any
file, anywhere on your filesystems?  E.g., can you try on a drive
other than C: ?

Also, do you, as the user, own the directory where this file lives, or
is its owner another user?

And what filesystem is that? NTFS or FAT32?

Finally, does this happen in "emacs -Q", or do you need some
customizations for the problem to happen?

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Thu, 25 Feb 2016 18:47:39 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 24 Feb 2016 13:57:49 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > Wed, 24 Feb 2016 21:09:57 +0200: Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > > > Date: Wed, 24 Feb 2016 08:44:02 -0800
> > > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > > 
> > > > When a file is read only on w32 platform I used to be able to write a
> > > > file by toggling the buffer's read-only-mode state and answering yes
> > > > to this question "File memo is write-protected; try to save anyway?
> > > > (yes or no)" but now the writing fails by an error message "Opening
> > > > output file: Permission denied, c:/d/ota/memo"
> > > 
> > > I cannot reproduce this, neither with today's emacs-25 nor with the
> > > last pretest of 25.1.  If I answer yes to that question, the file is
> > > saved without any errors.
> > > 
> > > How did you make the file read-only?  (I used a Windows port of
> > > 'chmod' and the 'attrib' command.)
> > 
> > I used Windows Explorer's GUI to open the file property window and
> > placed a check on Read-only attribute.  I am using mingw to build the
> > emacs.  I just tried with 24.5 and it works but not on 25.0.90/91.
> > They are all build by the same mingw.
> 
> This doesn't happen for me even if I use the Explorer.
> 
> There's some other factor at work here.  Does this happen with any
> file, anywhere on your filesystems?  E.g., can you try on a drive
> other than C: ?
> 
> Also, do you, as the user, own the directory where this file lives, or
> is its owner another user?
> 
> And what filesystem is that? NTFS or FAT32?
> 
> Finally, does this happen in "emacs -Q", or do you need some
> customizations for the problem to happen?
> 
> Thanks.
> 

Yes, I own and have full permission of the directory.  I noticed one
thing when I tried other than C: drive.  An external USB drive with
NTFS file system exhibits the same problem as C: drive.  A flash drive
with FAT32 doesn't show the same problem.  Have you tried with NTFS?

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Thu, 25 Feb 2016 09:08:38 -0800 (Pacific Standard Time): "Ota, Takaaki" <Takaaki.Ota@am.sony.com> wrote:

> Thu, 25 Feb 2016 18:47:39 +0200: Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > Date: Wed, 24 Feb 2016 13:57:49 -0800
> > > CC: <22795@debbugs.gnu.org>
> > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > 
> > > Wed, 24 Feb 2016 21:09:57 +0200: Eli Zaretskii <eliz@gnu.org> wrote:
> > > 
> > > > > Date: Wed, 24 Feb 2016 08:44:02 -0800
> > > > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > > > 
> > > > > When a file is read only on w32 platform I used to be able to write a
> > > > > file by toggling the buffer's read-only-mode state and answering yes
> > > > > to this question "File memo is write-protected; try to save anyway?
> > > > > (yes or no)" but now the writing fails by an error message "Opening
> > > > > output file: Permission denied, c:/d/ota/memo"
> > > > 
> > > > I cannot reproduce this, neither with today's emacs-25 nor with the
> > > > last pretest of 25.1.  If I answer yes to that question, the file is
> > > > saved without any errors.
> > > > 
> > > > How did you make the file read-only?  (I used a Windows port of
> > > > 'chmod' and the 'attrib' command.)
> > > 
> > > I used Windows Explorer's GUI to open the file property window and
> > > placed a check on Read-only attribute.  I am using mingw to build the
> > > emacs.  I just tried with 24.5 and it works but not on 25.0.90/91.
> > > They are all build by the same mingw.
> > 
> > This doesn't happen for me even if I use the Explorer.
> > 
> > There's some other factor at work here.  Does this happen with any
> > file, anywhere on your filesystems?  E.g., can you try on a drive
> > other than C: ?
> > 
> > Also, do you, as the user, own the directory where this file lives, or
> > is its owner another user?
> > 
> > And what filesystem is that? NTFS or FAT32?
> > 
> > Finally, does this happen in "emacs -Q", or do you need some
> > customizations for the problem to happen?
> > 
> > Thanks.
> > 
> 
> Yes, I own and have full permission of the directory.  I noticed one
> thing when I tried other than C: drive.  An external USB drive with
> NTFS file system exhibits the same problem as C: drive.  A flash drive
> with FAT32 doesn't show the same problem.  Have you tried with NTFS?
> 
> -Tak

I tried "emacs -Q" (actually "./runemacs -Q") and the result is the
same.  On FAT32 the writing succeeds.  On NTFS the writing fails by
Permission denied error.

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Thu, 25 Feb 2016 09:08:38 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> Yes, I own and have full permission of the directory.  I noticed one
> thing when I tried other than C: drive.  An external USB drive with
> NTFS file system exhibits the same problem as C: drive.  A flash drive
> with FAT32 doesn't show the same problem.  Have you tried with NTFS?

I tried only with NTFS.

> I tried "emacs -Q" (actually "./runemacs -Q") and the result is the
> same.  On FAT32 the writing succeeds.  On NTFS the writing fails by
> Permission denied error.

Very strange.  I guess the only way forward is for you to step with
Edebug through save-buffer and its subroutines in files.el, and tell
what fails there and why.  Can you do that?  (Since this works on
FAT32, I suspect some issue with NT security, although 24.5 also used
ACLs...)

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Thu, 25 Feb 2016 20:09:34 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 25 Feb 2016 09:08:38 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > Yes, I own and have full permission of the directory.  I noticed one
> > thing when I tried other than C: drive.  An external USB drive with
> > NTFS file system exhibits the same problem as C: drive.  A flash drive
> > with FAT32 doesn't show the same problem.  Have you tried with NTFS?
> 
> I tried only with NTFS.
> 
> > I tried "emacs -Q" (actually "./runemacs -Q") and the result is the
> > same.  On FAT32 the writing succeeds.  On NTFS the writing fails by
> > Permission denied error.
> 
> Very strange.  I guess the only way forward is for you to step with
> Edebug through save-buffer and its subroutines in files.el, and tell
> what fails there and why.  Can you do that?  (Since this works on
> FAT32, I suspect some issue with NT security, although 24.5 also used
> ACLs...)
> 
> Thanks.
> 

I will try.

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

I think this is something to do with my mingw.  I cannot remember when
I updated mingw last time.  Here is the comparison between trace in
emacs-24.5 and emacs-25.0.91.  The difference is in the open system
call.  Both pass the same set of parameters to open but emacs-24.5
gets 3 and emacs-25.0.91 gets -1.  Both emacs were built using mingw
but I cannot guarantee they are the same version of mingw.  Can you
think of any other reason than they were built with different mingw to
explain the difference of the open() behavior?

-Tak

================================ emacs-25.0.91
[New Thread 10664.0x2714]
4707      bool file_locked = 0;
(gdb) 
4801      if (open_and_close_file && !auto_saving)
(gdb) 
4803          lock_file (lockname);
(gdb) 
4804          file_locked = 1;
(gdb) 
4807      encoded_filename = ENCODE_FILE (filename);
(gdb) 
4808      fn = SSDATA (encoded_filename);
(gdb) 
4810      open_flags |= EQ (mustbenew, Qexcl) ? O_EXCL : !NILP (append) ? 0 : O_TRUNC;
(gdb) 
4811      if (NUMBERP (append))
(gdb) 
4810      open_flags |= EQ (mustbenew, Qexcl) ? O_EXCL : !NILP (append) ? 0 : O_TRUNC;
(gdb) 
4821      if (open_and_close_file)
(gdb) 
4823          desc = emacs_open (fn, open_flags, mode);
(gdb) s
emacs_open (file=file@entry=0x829692c "c:/d/ota/memo", 
    oflags=oflags@entry=33537, mode=mode@entry=384) at sysdep.c:2260
2260    {
(gdb) n
2263        oflags |= O_BINARY;
(gdb) 
2264      oflags |= O_CLOEXEC;
(gdb) 
2265      while ((fd = open (file, oflags, mode)) < 0 && errno == EINTR)
(gdb) p file
$10 = 0x829692c "c:/d/ota/memo"
(gdb) p oflags
$11 = 33665
(gdb) p mode
$12 = 384
(gdb) n
2270    }
(gdb) p fd
$13 = -1

================================ emacs-24.5
[New Thread 3264.0xa38]
4708      bool file_locked = 0;
(gdb) 
4809      if (open_and_close_file && !auto_saving)
(gdb) 
4811          lock_file (lockname);
(gdb) 
4812          file_locked = 1;
(gdb) 
4816      encoded_filename = ENCODE_FILE (filename);
(gdb) 
4817      fn = SSDATA (encoded_filename);
(gdb) 
4819      open_flags |= EQ (mustbenew, Qexcl) ? O_EXCL : !NILP (append) ? 0 : O_TRUNC;
(gdb) 
4820      if (NUMBERP (append))
(gdb) 
4823        open_flags |= O_APPEND;
(gdb) 
4830      if (open_and_close_file)
(gdb) 
4832          desc = emacs_open (fn, open_flags, mode);
(gdb) s
emacs_open (file=file@entry=0x5d8aec8 "c:/d/ota/memo", 
    oflags=oflags@entry=33537, mode=mode@entry=384) at sysdep.c:2143
2143    {
(gdb) n
2145      oflags |= O_CLOEXEC;
(gdb) 
2146      while ((fd = open (file, oflags, mode)) < 0 && errno == EINTR)
(gdb) p file
$1 = 0x5d8aec8 "c:/d/ota/memo"
(gdb) p oflags
$2 = 33665
(gdb) p mode
$3 = 384
(gdb) n
[New Thread 3264.0x4f0]
[New Thread 3264.0x12a0]
2151    }
(gdb) p fd
$4 = 3



Thu, 25 Feb 2016 20:09:34 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 25 Feb 2016 09:08:38 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > Yes, I own and have full permission of the directory.  I noticed one
> > thing when I tried other than C: drive.  An external USB drive with
> > NTFS file system exhibits the same problem as C: drive.  A flash drive
> > with FAT32 doesn't show the same problem.  Have you tried with NTFS?
> 
> I tried only with NTFS.
> 
> > I tried "emacs -Q" (actually "./runemacs -Q") and the result is the
> > same.  On FAT32 the writing succeeds.  On NTFS the writing fails by
> > Permission denied error.
> 
> Very strange.  I guess the only way forward is for you to step with
> Edebug through save-buffer and its subroutines in files.el, and tell
> what fails there and why.  Can you do that?  (Since this works on
> FAT32, I suspect some issue with NT security, although 24.5 also used
> ACLs...)
> 
> Thanks.
> 

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Fri, 26 Feb 2016 11:26:05 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> I think this is something to do with my mingw.  I cannot remember when
> I updated mingw last time.  Here is the comparison between trace in
> emacs-24.5 and emacs-25.0.91.  The difference is in the open system
> call.  Both pass the same set of parameters to open but emacs-24.5
> gets 3 and emacs-25.0.91 gets -1.  Both emacs were built using mingw
> but I cannot guarantee they are the same version of mingw.

I very much doubt this has something to do with MinGW, because MinGW
uses the Windows runtime library, so running the two executables on
the same box will use the same library.

> Can you think of any other reason than they were built with
> different mingw to explain the difference of the open() behavior?

Step into the 'open' call -- it's shadowed by 'sys_open' defined on
w32.c.  What flags are passed to _wopen in each case?  Your trace from
GDB seems to indicate that in the case of 25.0.91 we pass O_BINARY,
while in 24.5 we don't.  If this is really the case, maybe that's the
reason, although I don't currently see why it would lead to a failure
(and it certainly doesn't fail for me).  Is there any other difference
in flags and modes with which we call _wopen in each case?

Also, I think by the time this code is run, the original file should
have been renamed to the backup-file name, so the file you are saving
should not exist on disk by the time we open it.  If that is not the
case with 25.0.91, then perhaps what fails is not the open call, but
the rename call before that.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Fri, 26 Feb 2016 23:53:33 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 26 Feb 2016 11:26:05 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > I think this is something to do with my mingw.  I cannot remember when
> > I updated mingw last time.  Here is the comparison between trace in
> > emacs-24.5 and emacs-25.0.91.  The difference is in the open system
> > call.  Both pass the same set of parameters to open but emacs-24.5
> > gets 3 and emacs-25.0.91 gets -1.  Both emacs were built using mingw
> > but I cannot guarantee they are the same version of mingw.
> 
> I very much doubt this has something to do with MinGW, because MinGW
> uses the Windows runtime library, so running the two executables on
> the same box will use the same library.
> 
> > Can you think of any other reason than they were built with
> > different mingw to explain the difference of the open() behavior?
> 
> Step into the 'open' call -- it's shadowed by 'sys_open' defined on
> w32.c.  What flags are passed to _wopen in each case?  Your trace from
> GDB seems to indicate that in the case of 25.0.91 we pass O_BINARY,
> while in 24.5 we don't.  If this is really the case, maybe that's the
> reason, although I don't currently see why it would lead to a failure
> (and it certainly doesn't fail for me).  Is there any other difference
> in flags and modes with which we call _wopen in each case?
> 
> Also, I think by the time this code is run, the original file should
> have been renamed to the backup-file name, so the file you are saving
> should not exist on disk by the time we open it.  If that is not the
> case with 25.0.91, then perhaps what fails is not the open call, but
> the rename call before that.
> 
> Thanks.
> 

I am now very much puzzled.  Here is the trace up to _wopen().  I
printed parameters to _wopen() and they are identical yet one succeeds
and the other fails.

================================ emacs-24.5 =====================================

4819      open_flags |= EQ (mustbenew, Qexcl) ? O_EXCL : !NILP (append) ? 0 : O_TRUNC;
(gdb) 
4820      if (NUMBERP (append))
(gdb) 
4823        open_flags |= O_APPEND;
(gdb) 
4830      if (open_and_close_file)
(gdb) 
4832          desc = emacs_open (fn, open_flags, mode);
(gdb) s
emacs_open (file=file@entry=0x5bf6ec8 "c:/d/ota/memo", 
    oflags=oflags@entry=33537, mode=mode@entry=384) at sysdep.c:2143
2143    {
(gdb) n
2145      oflags |= O_CLOEXEC;
(gdb) 
2146      while ((fd = open (file, oflags, mode)) < 0 && errno == EINTR)
(gdb) s
sys_open (path=path@entry=0x5bf6ec8 "c:/d/ota/memo", oflag=oflag@entry=33665, 
    mode=mode@entry=384) at w32.c:4172
4172    {
(gdb) n
4173      const char* mpath = map_w32_filename (path, NULL);
(gdb) 
4180          filename_to_utf16 (mpath, mpath_w);
(gdb) 
4176      if (w32_unicode_filenames)
(gdb) 
4180          filename_to_utf16 (mpath, mpath_w);
(gdb) 
4176      if (w32_unicode_filenames)
(gdb) 
4180          filename_to_utf16 (mpath, mpath_w);
(gdb) 
4184          if ((oflag & (_O_CREAT | _O_EXCL)) != (_O_CREAT | _O_EXCL))
(gdb) 
4185            res = _wopen (mpath_w, (oflag & ~_O_CREAT) | _O_NOINHERIT, mode);
(gdb) p mpath_w
$1 = L"c:\\d\\ota\\memo\000\340\074\311\003\000\000\300\235\017\001\001\000\xe558\210\364\141\073\005\xf822\255\003\116\137\x5c9\xf822\255\003\325\245\334\003\xe554\210\b\000\xe550\210\xe648\210\375\226\022\001\030\000\xf822\255\003\xf822\255\003\000\000\n\000\102\225\312\003\142\372\256\003\102\225\312\003\xf822\255\003\xf822\255\003\xf822\255\003\000\000\272\374\075\167@\000\065\302\057\001\320\224\022\001\000\000\000\000\000\000\000\000\xe5a4\210\000\000\340\245\077\001\350\245\077\001\000\000\000\000\334\136\325\120\352\013\000ä\000\003\001\000\xed4b\320\126\154\153\030\001\000\000\000\000\xe60c\210\324\134\027\001\003\000\xe60c\210\000\000\xe600\210\000\255\x1fb5\000\255\x1fb5\xe6e8\210\330\162\023\001\003\000\xe60c\210\000\000\000\255\x1fb5\030\000\030\000\002\000\000\100\000\342\374\312\003\340\374\312\003\344\267\042\001\300\235\017\001\121\305\057\001\321\267\042\001\220\141\073\005\xf822\255\003\000\255\x1fb5\000\255\x1fb5\xed4b\320\126\220\267\042\001\005\000\005\000\350\265\034\001\071\212\017\001\023\000\102\225\312\003$\000\xf822\255\003\000\000\000\000\xf822\255\003\xe70c\210\xed4b\000\001\225\267\042\001"...
(gdb) p oflag
$2 = 33665
(gdb) p mode
$3 = 384
(gdb) s
4186          if (res < 0)
(gdb) p res
$4 = 3

================================ emacs-25.0.91 =====================================

4810      open_flags |= EQ (mustbenew, Qexcl) ? O_EXCL : !NILP (append) ? 0 : O_TRUNC;
(gdb) 
4811      if (NUMBERP (append))
(gdb) 
4810      open_flags |= EQ (mustbenew, Qexcl) ? O_EXCL : !NILP (append) ? 0 : O_TRUNC;
(gdb) 
4821      if (open_and_close_file)
(gdb) 
4823          desc = emacs_open (fn, open_flags, mode);
(gdb) s
emacs_open (file=file@entry=0x883a4ac "c:/d/ota/memo", 
    oflags=oflags@entry=33537, mode=mode@entry=384) at sysdep.c:2260
2260    {
(gdb) n
2263        oflags |= O_BINARY;
(gdb) 
2264      oflags |= O_CLOEXEC;
(gdb) 
2265      while ((fd = open (file, oflags, mode)) < 0 && errno == EINTR)
(gdb) s
sys_open (path=path@entry=0x883a4ac "c:/d/ota/memo", oflag=oflag@entry=33665, 
    mode=mode@entry=384) at w32.c:4290
4290    {
(gdb) n
4291      const char* mpath = map_w32_filename (path, NULL);
(gdb) 
4298          filename_to_utf16 (mpath, mpath_w);
(gdb) 
4294      if (w32_unicode_filenames)
(gdb) 
4298          filename_to_utf16 (mpath, mpath_w);
(gdb) 
4294      if (w32_unicode_filenames)
(gdb) 
4298          filename_to_utf16 (mpath, mpath_w);
(gdb) 
4302          if ((oflag & (_O_CREAT | _O_EXCL)) != (_O_CREAT | _O_EXCL))
(gdb) 
4303            res = _wopen (mpath_w, (oflag & ~_O_CREAT) | _O_NOINHERIT, mode);
(gdb) p mpath_w
$2 = L"c:\\d\\ota\\memo\000\006\000\002\145\021\133\321\x889\000\000\324\302\x82d\300\170\000\310\317\123\377\310\317\123\377\310\317\123\377^\000\063\317\x889\000\000\000\000\310\317\123\377\040\201\000\310\317\123\377\002\000ä\000\000\000\xe3dc\210p\000\062\117\061\001\073\255\022\001\000\160\375\176\154\041\000\074\030\000ÿ\000\n\000\000\000\xe488\210\xa69a\027\001ä\000\xe454\210\100\102\017\000\000'\000\110\121·\xe51c\210\045\143\103\167\000\000\000\000\000\000\000\000\xe444\210\000\000\x29e0\001\002\x29e8\001\002\000\000\000\000\xddf1\327\120\352\013\000\xe380\210\005\000\002\000\120\213\030\002\005\000\xd868\042\001\000\000\000\000\023\000\023\000\xd86c\042\001\xe4a0\210\021\122\061\001\xd85c\042\001\062\117\061\001\xee70\210\000\000\xe4a0\210\xedef\320\126\xd840\042\001\022\000\012\024\000\xe58c\210\164\261\017\001\xd85c\042\001\xd86d\042\001R\000\012\024\000\005\000\xe58c\210\005\000\xe58c\210\000\000\xd845\042\001\xf658\x805\xf4dc\x805\022\000\000\000\002\145\021\xd840\042\001\022\000\160\214\135\377"...
(gdb) p oflag
$3 = 33665
(gdb) p mode
$4 = 384
(gdb) s
[New Thread 8556.0x2230]
[New Thread 8556.0x12c4]
4304          if (res < 0)
(gdb) p res
$5 = -1

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 29 Feb 2016 08:40:35 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> I am now very much puzzled.  Here is the trace up to _wopen().  I
> printed parameters to _wopen() and they are identical yet one succeeds
> and the other fails.

Hmm... strange, indeed.

Do you have a dependency walker program?  (If not, you can download it
from http://www.dependencywalker.com/.)  Can you tell whether the two
executables differ in the versions of msvcrt.dll they are linked
against?  Or any other dynamic libraries, for that matter?

Also, what is the value of errno after the _wopen call that fails?

Finally, what about this part of my questions, did you look into this:

> Also, I think by the time this code is run, the original file should
> have been renamed to the backup-file name, so the file you are saving
> should not exist on disk by the time we open it.  If that is not the
> case with 25.0.91, then perhaps what fails is not the open call, but
> the rename call before that.

Does the file that Emacs tries to open here, c:\d\ota\memo, exist when
_wopen is called, and if so, is it read-only?  Please check this with
both versions of Emacs, and see if there's any differences in what
happens.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Mon, 29 Feb 2016 19:13:43 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 29 Feb 2016 08:40:35 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > I am now very much puzzled.  Here is the trace up to _wopen().  I
> > printed parameters to _wopen() and they are identical yet one succeeds
> > and the other fails.
> 
> Hmm... strange, indeed.
> 
> Do you have a dependency walker program?  (If not, you can download it
> from http://www.dependencywalker.com/.)  Can you tell whether the two
> executables differ in the versions of msvcrt.dll they are linked
> against?  Or any other dynamic libraries, for that matter?

Both depends on C:\windows\system32\MSVCRT.DLL

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Mon, 29 Feb 2016 19:13:43 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 29 Feb 2016 08:40:35 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > I am now very much puzzled.  Here is the trace up to _wopen().  I
> > printed parameters to _wopen() and they are identical yet one succeeds
> > and the other fails.
> 
> Hmm... strange, indeed.
> 
> Do you have a dependency walker program?  (If not, you can download it
> from http://www.dependencywalker.com/.)  Can you tell whether the two
> executables differ in the versions of msvcrt.dll they are linked
> against?  Or any other dynamic libraries, for that matter?
> 
> Also, what is the value of errno after the _wopen call that fails?

4303            res = _wopen (mpath_w, (oflag & ~_O_CREAT) | _O_NOINHERIT, mode);
(gdb) s
4304          if (res < 0)
(gdb) p res
$6 = -1
(gdb) p errno
$7 = 13

So it must be this.

#define	EACCES		13	/* Permission denied */

> 
> Finally, what about this part of my questions, did you look into this:
> 
> > Also, I think by the time this code is run, the original file should
> > have been renamed to the backup-file name, so the file you are saving
> > should not exist on disk by the time we open it.  If that is not the
> > case with 25.0.91, then perhaps what fails is not the open call, but
> > the rename call before that.
> 
> Does the file that Emacs tries to open here, c:\d\ota\memo, exist when
> _wopen is called, and if so, is it read-only?  Please check this with
> both versions of Emacs, and see if there's any differences in what
> happens.

In both cases the original file exists right before calling _wopen()
but there is a difference.  On 25.0.91 the file remains read-only but
on 24.5 the file is writable right before calling _open().  Now we
have some clue here.

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Mon, 29 Feb 2016 09:53:54 -0800 (Pacific Standard Time): "Ota, Takaaki" <Takaaki.Ota@am.sony.com> wrote:

> Mon, 29 Feb 2016 19:13:43 +0200: Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Finally, what about this part of my questions, did you look into this:
> > 
> > > Also, I think by the time this code is run, the original file should
> > > have been renamed to the backup-file name, so the file you are saving
> > > should not exist on disk by the time we open it.  If that is not the
> > > case with 25.0.91, then perhaps what fails is not the open call, but
> > > the rename call before that.
> > 
> > Does the file that Emacs tries to open here, c:\d\ota\memo, exist when
> > _wopen is called, and if so, is it read-only?  Please check this with
> > both versions of Emacs, and see if there's any differences in what
> > happens.
> 
> In both cases the original file exists right before calling _wopen()
> but there is a difference.  On 25.0.91 the file remains read-only but
> on 24.5 the file is writable right before calling _open().  Now we
> have some clue here.
> 

I set a break pointer at write_region() in fileio.c and then perform
the save-buffer command.  When emacs breaks at write_region() on 24.5
the file's permission is changed to writable while on 25.0.91 the
permission remains read-only.  I will trace in lisp from save-buffer
to write-region on each version to find how this permission difference
is made.

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 29 Feb 2016 10:05:26 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> I set a break pointer at write_region() in fileio.c and then perform
> the save-buffer command.  When emacs breaks at write_region() on 24.5
> the file's permission is changed to writable while on 25.0.91 the
> permission remains read-only.

Both results are wrong: the file should not exist when write_region is
called, because Emacs renamed it to the backup-file name.  The problem
is most probably in making the backup, so I suggest looking at
sys_rename instead.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Mon, 29 Feb 2016 20:48:30 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 29 Feb 2016 10:05:26 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > I set a break pointer at write_region() in fileio.c and then perform
> > the save-buffer command.  When emacs breaks at write_region() on 24.5
> > the file's permission is changed to writable while on 25.0.91 the
> > permission remains read-only.
> 
> Both results are wrong: the file should not exist when write_region is
> called, because Emacs renamed it to the backup-file name.  The problem
> is most probably in making the backup, so I suggest looking at
> sys_rename instead.
> 

emacs-24.5 never called sys_rename().

emacs-25.0.91 calls sys_rename() but strangely old name and the new
name are the same.  See below.

-Tak

Breakpoint 1, sys_rename (old=0x880c9b8 "c:/d/ota/memo", 
    new=0x880c9b8 "c:/d/ota/memo") at w32.c:4543
4543    {
(gdb) n
4544      return sys_rename_replace (old, new, TRUE);
(gdb) s
sys_rename_replace (oldname=oldname@entry=0x880c9b8 "c:/d/ota/memo", 
    newname=newname@entry=0x880c9b8 "c:/d/ota/memo", force=force@entry=1)
    at w32.c:4404
4404      strcpy (temp, map_w32_filename (oldname, NULL));
(gdb) n
4407      oldname_dev = volume_info.serialnum;
(gdb) 
4409      if (os_subtype == OS_9X)
(gdb) 
4416          oldname = map_w32_filename (oldname, NULL);
(gdb) 
4409      if (os_subtype == OS_9X)
(gdb) 
4455      newname = map_w32_filename (newname, NULL);
(gdb) 
4458      newname_dev = volume_info.serialnum;
(gdb) 
4460      if (w32_unicode_filenames)
(gdb) 
4464          filename_to_utf16 (temp, temp_w);
(gdb) 
4465          filename_to_utf16 (newname, newname_w);
(gdb) 
4466          result = _wrename (temp_w, newname_w);
(gdb) p temp
$12 = "c:\\d\\ota\\memo\000\210\000Jº>w`P©\000\000\000¨\000\000\000¨\000Jº>w`P©\000<Þ\210\000h'Iw8\001¨\000L'IwÀ9]o\000\000¨\000\000\000¨\000\000\000\000\000\000\000¨\000\000\000\000\000\000\000\001\001\bÞ\210\000\000\000\000\000 ß\210\000%cCwì5ë\030þÿÿÿL'Iw¢²Dw\000\000¨\000c\000\000Pí0?wÌ8]o\000\000\000\000\000\000¨\000hP©", '\000' <repeats 39 times>, "¨", '\000' <repeats 41 times>...
(gdb) p temp_w
$13 = L"c:\\d\\ota\\memo\000\120\177ª\025\000G\000\354\023\100\001G\000\030\304\034\001\025\000\260\001\001\220\122©\000\000\002\x604\x2490¨\304\001\004\301\270\023\100\001\030\304\034\001\000\000\177\000\030\304\034\001\xf613\xe104\050\002\000\000\000\032\000\143\001\000\120\036\000\150\120©\150\120©\143\120©\000\000\000\000\000¨\a\x300\xd9a0\210\070\201\034\001\xdb30\210\045\143\103\167\014\056\x18eb\xfffe\xffff\026\065\077\167\101\065\077\167\032\002\000\070\002\000\142\120©\140\120©\032\002\000\000¨\001\000\005\000\xe440\x80a\xe24c\x80a\143\072\\\000\000\xdb64\210\250\066\067\001\030\000\x2158\xff40\xdb50\210\246\264\017\001\006\000\xdb50\210\xdaf8\210\x17be\111\167\000¨\000\000\032\002\000\000¨\001\000\004\000\000\000\140\120©\000\000\000¨\xdb40\210\102\040\111\167\070\001¨…\111\167\274\074\135\157\000\000\000\000\000¨\002\000\000\000\150\120©\xdb64\210\001\xdb08\210\222\256\022\001\xdc14\210\045\143\103\167\074\066\x18eb\xfffe\xffff…\111\167\206\265\104\167\000¨\143\001\000\120"...
(gdb) p newname
$14 = 0x1404ce0 <shortname.46207> "c:\\d\\ota\\memo"
(gdb) p newname_w
$15 = L"c:\\d\\ota\\memo\000\xdcd0\210\000\000\032\034\xdcd0\210\002\000\xdc9c\210\xe322\076\167\066\263\077\167\140\073\135\157\000\000\010\002\000\150\120©\304\377\210\045\143\103\167\000\000\xfffe\xffff\r\000\032\034\xdfd8\210\000\000\002\000\000\000\032\000\000\000\032\000\xdd1a\210\xdfd8\210C\000\001\032\010\002\xdd00\210\xdff2\210\000\000\000\000\000\000\120\001¨\003\000\032\000\204\006\100\001c\000\140\073\135\157\xdc04\210\001\000\304\377\210\045\143\103\167\000\000\114\152\332\005\375\271\015\001\114\152\332\005\000\000\001\000\032\000\150\120©\002\000\204\006\100\001c\000\x650\100\001 \000\270\001\000\314\311\x880\000\000\000\000\004\000\xddd4\210\x650\100\001\x650\100\001\210\007\100\001\000\144\130\001\114\152\332\005\000\000\210\145\130\001\106\307\015\001\140\006\100\001\000\000\000\000\314\311\x880        \000\000\000\000\000\000\000    \000\120\001¨\000¨\000\144\130\001\114\152\332\005\000\000\210\145\130\001\122\102\015\001\140\006\100\001\314\311\x880       \000\000\000    \000\000\000\000\000\000\000\000\000"...
(gdb) n
[New Thread 10660.0x29f4]
[New Thread 10660.0x2904]
4467          if (result < 0 && force)
(gdb) p result
$16 = 0
(gdb) n
4527                    return result;
(gdb) 
4539    }
(gdb) 
sys_rename (old=0x880c9b8 "c:/d/ota/memo", new=0x880c9b8 "c:/d/ota/memo")
    at w32.c:4545
4545    }

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 29 Feb 2016 11:28:15 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> emacs-24.5 never called sys_rename().

??? It does here.  The call is in backup-buffer: it calls rename-file.

Are you trying this in "emacs -Q"?  If not, perhaps you have some
customizations, like backup-by-copying or
backup-by-copying-when-mismatch etc.?

> emacs-25.0.91 calls sys_rename() but strangely old name and the new
> name are the same.  See below.
> 
> -Tak
> 
> Breakpoint 1, sys_rename (old=0x880c9b8 "c:/d/ota/memo", 
>     new=0x880c9b8 "c:/d/ota/memo") at w32.c:4543
> 4543    {
> (gdb) n
> 4544      return sys_rename_replace (old, new, TRUE);
> (gdb) s
> sys_rename_replace (oldname=oldname@entry=0x880c9b8 "c:/d/ota/memo", 
>     newname=newname@entry=0x880c9b8 "c:/d/ota/memo", force=force@entry=1)
>     at w32.c:4404

Again, is this in "emacs -Q"?  The backup file name is generated by
the function find-backup-file-name, you will find it in files.el.  It
is called by backup-buffer.  Please see what file names it produces in
this case.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Mon, 29 Feb 2016 22:06:39 +0200: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 29 Feb 2016 11:28:15 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > emacs-24.5 never called sys_rename().
> 
> ??? It does here.  The call is in backup-buffer: it calls rename-file.
> 
> Are you trying this in "emacs -Q"?  If not, perhaps you have some
> customizations, like backup-by-copying or
> backup-by-copying-when-mismatch etc.?
> 
> > emacs-25.0.91 calls sys_rename() but strangely old name and the new
> > name are the same.  See below.
> > 
> > -Tak
> > 
> > Breakpoint 1, sys_rename (old=0x880c9b8 "c:/d/ota/memo", 
> >     new=0x880c9b8 "c:/d/ota/memo") at w32.c:4543
> > 4543    {
> > (gdb) n
> > 4544      return sys_rename_replace (old, new, TRUE);
> > (gdb) s
> > sys_rename_replace (oldname=oldname@entry=0x880c9b8 "c:/d/ota/memo", 
> >     newname=newname@entry=0x880c9b8 "c:/d/ota/memo", force=force@entry=1)
> >     at w32.c:4404
> 
> Again, is this in "emacs -Q"?  The backup file name is generated by
> the function find-backup-file-name, you will find it in files.el.  It
> is called by backup-buffer.  Please see what file names it produces in
> this case.
> 

I just tried again with "run -Q" from gdb and the result is the same.
24.5 never called sys_rename() and 25.0.91 called sys_rename() with
two same names.

-Tak

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 29 Feb 2016 13:34:36 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> I just tried again with "run -Q" from gdb and the result is the same.
> 24.5 never called sys_rename() and 25.0.91 called sys_rename() with
> two same names.

What about Frename_file? does 24.5 call it in this scenario?

If it doesn't, then please look at the beginning of backup-buffer (in
files.el), make sure it is called in 24.5 in this scenario, and then
please tell what are the values of real-file-name and backup-info in
this part at the beginning of backup-buffer:

	(let* ((real-file-name (file-chase-links buffer-file-name))
	       (backup-info (find-backup-file-name real-file-name)))

Also, what are the values of make-backup-files, backup-inhibited, and
buffer-backed-up in the buffer that visits the read-only file?

Btw, is that file under some kind of version control, per chance?

And please make sure, from now on, to test everything in "emacs -Q",
to prevent any customizations from getting in the way of this
investigation.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Tue, 01 Mar 2016 18:27:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22795@debbugs.gnu.org
> 
> > Date: Mon, 29 Feb 2016 13:34:36 -0800
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > I just tried again with "run -Q" from gdb and the result is the same.
> > 24.5 never called sys_rename() and 25.0.91 called sys_rename() with
> > two same names.
> 
> What about Frename_file? does 24.5 call it in this scenario?
> 
> If it doesn't, then please look at the beginning of backup-buffer (in
> files.el), make sure it is called in 24.5 in this scenario, and then
> please tell what are the values of real-file-name and backup-info in
> this part at the beginning of backup-buffer:
> 
> 	(let* ((real-file-name (file-chase-links buffer-file-name))
> 	       (backup-info (find-backup-file-name real-file-name)))
> 
> Also, what are the values of make-backup-files, backup-inhibited, and
> buffer-backed-up in the buffer that visits the read-only file?
> 
> Btw, is that file under some kind of version control, per chance?
> 
> And please make sure, from now on, to test everything in "emacs -Q",
> to prevent any customizations from getting in the way of this
> investigation.

Ping!  Can we please continue this investigation?

If the problem is no longer reproducible with the latest pretest
25.0.9x, or if you can no longer afford looking into this, I will most
probably close the bug.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Sorry, I haven't made much progress.  I confirmed that it was
reproducible with the latest 25.0.94.  Let me resume looking into it
and I will send you further facts and questions.

-Tak

Sat, 14 May 2016 12:17:03 +0300: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 01 Mar 2016 18:27:35 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 22795@debbugs.gnu.org
> > 
> > > Date: Mon, 29 Feb 2016 13:34:36 -0800
> > > CC: <22795@debbugs.gnu.org>
> > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > 
> > > I just tried again with "run -Q" from gdb and the result is the same.
> > > 24.5 never called sys_rename() and 25.0.91 called sys_rename() with
> > > two same names.
> > 
> > What about Frename_file? does 24.5 call it in this scenario?
> > 
> > If it doesn't, then please look at the beginning of backup-buffer (in
> > files.el), make sure it is called in 24.5 in this scenario, and then
> > please tell what are the values of real-file-name and backup-info in
> > this part at the beginning of backup-buffer:
> > 
> > 	(let* ((real-file-name (file-chase-links buffer-file-name))
> > 	       (backup-info (find-backup-file-name real-file-name)))
> > 
> > Also, what are the values of make-backup-files, backup-inhibited, and
> > buffer-backed-up in the buffer that visits the read-only file?
> > 
> > Btw, is that file under some kind of version control, per chance?
> > 
> > And please make sure, from now on, to test everything in "emacs -Q",
> > to prevent any customizations from getting in the way of this
> > investigation.
> 
> Ping!  Can we please continue this investigation?
> 
> If the problem is no longer reproducible with the latest pretest
> 25.0.9x, or if you can no longer afford looking into this, I will most
> probably close the bug.
> 
> Thanks.
> 

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Thu, 19 May 2016 11:47:51 -0700
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> Sorry, I haven't made much progress.  I confirmed that it was
> reproducible with the latest 25.0.94.  Let me resume looking into it
> and I will send you further facts and questions.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Sat, 14 May 2016 12:17:03 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22795@debbugs.gnu.org
> 
> > Date: Tue, 01 Mar 2016 18:27:35 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 22795@debbugs.gnu.org
> > 
> > > Date: Mon, 29 Feb 2016 13:34:36 -0800
> > > CC: <22795@debbugs.gnu.org>
> > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > 
> > > I just tried again with "run -Q" from gdb and the result is the same.
> > > 24.5 never called sys_rename() and 25.0.91 called sys_rename() with
> > > two same names.
> > 
> > What about Frename_file? does 24.5 call it in this scenario?
> > 
> > If it doesn't, then please look at the beginning of backup-buffer (in
> > files.el), make sure it is called in 24.5 in this scenario, and then
> > please tell what are the values of real-file-name and backup-info in
> > this part at the beginning of backup-buffer:
> > 
> > 	(let* ((real-file-name (file-chase-links buffer-file-name))
> > 	       (backup-info (find-backup-file-name real-file-name)))
> > 
> > Also, what are the values of make-backup-files, backup-inhibited, and
> > buffer-backed-up in the buffer that visits the read-only file?
> > 
> > Btw, is that file under some kind of version control, per chance?
> > 
> > And please make sure, from now on, to test everything in "emacs -Q",
> > to prevent any customizations from getting in the way of this
> > investigation.
> 
> Ping!  Can we please continue this investigation?
> 
> If the problem is no longer reproducible with the latest pretest
> 25.0.9x, or if you can no longer afford looking into this, I will most
> probably close the bug.
> 
> Thanks.

Ping!

Release of Emacs 25.1 is imminent, and I'd very much like to try to
fix this problem, whatever it is, for that release.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

I still don't have a conclusion but the root cause seems to be related
to file-ownership-preserved-p that has some platform specific
implementation.  When I open a read only file on both Linux and
windows-nt, Linux returns t while windows-nt returns nil.

-Tak

Wed, 25 May 2016 19:55:45 +0300: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 14 May 2016 12:17:03 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 22795@debbugs.gnu.org
> > 
> > > Date: Tue, 01 Mar 2016 18:27:35 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > Cc: 22795@debbugs.gnu.org
> > > 
> > > > Date: Mon, 29 Feb 2016 13:34:36 -0800
> > > > CC: <22795@debbugs.gnu.org>
> > > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > > 
> > > > I just tried again with "run -Q" from gdb and the result is the same.
> > > > 24.5 never called sys_rename() and 25.0.91 called sys_rename() with
> > > > two same names.
> > > 
> > > What about Frename_file? does 24.5 call it in this scenario?
> > > 
> > > If it doesn't, then please look at the beginning of backup-buffer (in
> > > files.el), make sure it is called in 24.5 in this scenario, and then
> > > please tell what are the values of real-file-name and backup-info in
> > > this part at the beginning of backup-buffer:
> > > 
> > > 	(let* ((real-file-name (file-chase-links buffer-file-name))
> > > 	       (backup-info (find-backup-file-name real-file-name)))
> > > 
> > > Also, what are the values of make-backup-files, backup-inhibited, and
> > > buffer-backed-up in the buffer that visits the read-only file?
> > > 
> > > Btw, is that file under some kind of version control, per chance?
> > > 
> > > And please make sure, from now on, to test everything in "emacs -Q",
> > > to prevent any customizations from getting in the way of this
> > > investigation.
> > 
> > Ping!  Can we please continue this investigation?
> > 
> > If the problem is no longer reproducible with the latest pretest
> > 25.0.9x, or if you can no longer afford looking into this, I will most
> > probably close the bug.
> > 
> > Thanks.
> 
> Ping!
> 
> Release of Emacs 25.1 is imminent, and I'd very much like to try to
> fix this problem, whatever it is, for that release.
> 
> Thanks.
> 

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Wed, 1 Jun 2016 10:22:53 -0700
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> I still don't have a conclusion but the root cause seems to be related
> to file-ownership-preserved-p that has some platform specific
> implementation.  When I open a read only file on both Linux and
> windows-nt, Linux returns t while windows-nt returns nil.

Thanks.  Just to make sure I understand you correctly: which function
returns nil or t when you open a read-only file?

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

After opening a read only file, execute read-only-mode, modify the
file and try to save the file under emacs 25.0.94 on Linux and Windows
file-ownership-preserved-p returns non nil value on Linux and nil on
Windows.

But I spoke too early about this.  After this, I then compared emacs
25.0.94 and 24.5 on Windows.  On both version
file-ownership-preserved-p returns nil while save succeeds on 24.5 and
25.0.94 fails with "Opening output file: Permission denined," error.

So file-ownership-preserved-p is not the root cause.  I still need to
continue to chase.

-Tak

Sat, 4 Jun 2016 12:01:29 +0300: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 1 Jun 2016 10:22:53 -0700
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > I still don't have a conclusion but the root cause seems to be related
> > to file-ownership-preserved-p that has some platform specific
> > implementation.  When I open a read only file on both Linux and
> > windows-nt, Linux returns t while windows-nt returns nil.
> 
> Thanks.  Just to make sure I understand you correctly: which function
> returns nil or t when you open a read-only file?
> 

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 6 Jun 2016 09:24:23 -0700
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> After opening a read only file, execute read-only-mode, modify the
> file and try to save the file under emacs 25.0.94 on Linux and Windows
> file-ownership-preserved-p returns non nil value on Linux and nil on
> Windows.

What does (file-attributes FILENAME 'integer) return for that file?
And what does (user-uid) return?

> But I spoke too early about this.  After this, I then compared emacs
> 25.0.94 and 24.5 on Windows.  On both version
> file-ownership-preserved-p returns nil while save succeeds on 24.5 and
> 25.0.94 fails with "Opening output file: Permission denined," error.
> 
> So file-ownership-preserved-p is not the root cause.  I still need to
> continue to chase.

OK, thanks for the update.

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

Mon, 6 Jun 2016 22:10:29 +0300: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 6 Jun 2016 09:24:23 -0700
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > After opening a read only file, execute read-only-mode, modify the
> > file and try to save the file under emacs 25.0.94 on Linux and Windows
> > file-ownership-preserved-p returns non nil value on Linux and nil on
> > Windows.
> 
> What does (file-attributes FILENAME 'integer) return for that file?
> And what does (user-uid) return?

On Linux

(file-attributes "~/memo" 'integer)
(nil 1 1000 1000 (22351 8780 403703 908000) (22351 6556 219830 864000) (22351 6556 223830 864000) 1827 "-r--r--r--" t 131312 2049)
(user-uid)
1000

On Windows (both 24.5 and 25.0.94)

(file-attributes "~/memo" 'integer)
(nil 1 544 513 (21821 905 0 0) (22357 41339 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (1024 1 . 32777) (50396 . 34426))
(user-uid)
1001

> 
> > But I spoke too early about this.  After this, I then compared emacs
> > 25.0.94 and 24.5 on Windows.  On both version
> > file-ownership-preserved-p returns nil while save succeeds on 24.5 and
> > 25.0.94 fails with "Opening output file: Permission denined," error.
> > 
> > So file-ownership-preserved-p is not the root cause.  I still need to
> > continue to chase.
> 
> OK, thanks for the update.
> 

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 6 Jun 2016 13:46:32 -0700
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> Mon, 6 Jun 2016 22:10:29 +0300: Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > Date: Mon, 6 Jun 2016 09:24:23 -0700
> > > CC: <22795@debbugs.gnu.org>
> > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > 
> > > After opening a read only file, execute read-only-mode, modify the
> > > file and try to save the file under emacs 25.0.94 on Linux and Windows
> > > file-ownership-preserved-p returns non nil value on Linux and nil on
> > > Windows.
> > 
> > What does (file-attributes FILENAME 'integer) return for that file?
> > And what does (user-uid) return?
> 
> On Linux
> 
> (file-attributes "~/memo" 'integer)
> (nil 1 1000 1000 (22351 8780 403703 908000) (22351 6556 219830 864000) (22351 6556 223830 864000) 1827 "-r--r--r--" t 131312 2049)
> (user-uid)
> 1000
> 
> On Windows (both 24.5 and 25.0.94)
> 
> (file-attributes "~/memo" 'integer)
> (nil 1 544 513 (21821 905 0 0) (22357 41339 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (1024 1 . 32777) (50396 . 34426))
> (user-uid)
> 1001

This may be part of the problem: your home directory is not owned by
your user, it is owned by the Administrators group.  That is
definitely why file-ownership-preserved-p returns nil in your case,
but it can also be part of the larger problem we are investigating.
(On my machines, I always take ownership of the home directory and all
of its subdirectories, recursively, to avoid any ownership issues.)

bug#22795: 25.0.91; Can't write read only file on w32

[Ota, Takaaki]

I changed the ownership of the home directory.  Then performed the
next test.  Does this tell you anything?

(user-uid)
1001

;; I manually deleted ~/memo~ before this test

(file-attributes "~/memo" 'integer)
(nil 1 1001 513 (22359 18939 0 0) (22359 18939 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (1536 1 . 32777) (50396 . 34426))

;; Find the file, perform read-only-mode and then save it - the save succeed.

(file-attributes "~/memo~" 'integer)
(nil 1 1001 513 (22359 18939 0 0) (22359 18939 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (1536 1 . 32777) (50396 . 34426))

(file-attributes "~/memo" 'integer)
(nil 1 1001 513 (22359 20386 0 0) (22359 20386 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (16128 10 . 5242) (50396 . 34426))

;; close the file
;; Find the file, perform read-only-mode and then try to save again - the save fails by error "Cannot write backup file ..." "Removing old name: Permission denied ..."
;; And now

(file-attributes "~/memo~" 'integer)
(nil 1 1001 513 (22359 18939 0 0) (22359 18939 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (1536 1 . 32777) (50396 . 34426))

(file-attributes "~/memo" 'integer)
(nil 1 1001 513 (22359 20386 0 0) (22359 20386 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (16128 10 . 5242) (50396 . 34426))

(file-attributes "~/.emacs.d/%backup%~" 'integer)
(nil 1 1001 513 (20624 4722 0 0) (22359 18939 0 0) (20624 4722 0 0) 289738 "-r--r--r--" t (256 3 . 42744) (50396 . 34426))

-Tak

Tue, 7 Jun 2016 05:42:52 +0300: Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 6 Jun 2016 13:46:32 -0700
> > CC: <22795@debbugs.gnu.org>
> > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > 
> > Mon, 6 Jun 2016 22:10:29 +0300: Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > > > Date: Mon, 6 Jun 2016 09:24:23 -0700
> > > > CC: <22795@debbugs.gnu.org>
> > > > From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> > > > 
> > > > After opening a read only file, execute read-only-mode, modify the
> > > > file and try to save the file under emacs 25.0.94 on Linux and Windows
> > > > file-ownership-preserved-p returns non nil value on Linux and nil on
> > > > Windows.
> > > 
> > > What does (file-attributes FILENAME 'integer) return for that file?
> > > And what does (user-uid) return?
> > 
> > On Linux
> > 
> > (file-attributes "~/memo" 'integer)
> > (nil 1 1000 1000 (22351 8780 403703 908000) (22351 6556 219830 864000) (22351 6556 223830 864000) 1827 "-r--r--r--" t 131312 2049)
> > (user-uid)
> > 1000
> > 
> > On Windows (both 24.5 and 25.0.94)
> > 
> > (file-attributes "~/memo" 'integer)
> > (nil 1 544 513 (21821 905 0 0) (22357 41339 0 0) (20624 9296 0 0) 289738 "-r--r--r--" t (1024 1 . 32777) (50396 . 34426))
> > (user-uid)
> > 1001
> 
> This may be part of the problem: your home directory is not owned by
> your user, it is owned by the Administrators group.  That is
> definitely why file-ownership-preserved-p returns nil in your case,
> but it can also be part of the larger problem we are investigating.
> (On my machines, I always take ownership of the home directory and all
> of its subdirectories, recursively, to avoid any ownership issues.)
> 

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Tue, 7 Jun 2016 16:02:38 -0700
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> I changed the ownership of the home directory.  Then performed the
> next test.  Does this tell you anything?

Not really, no.  I guess we still need the answers to the questions I
asked back in March, repeated below:

> > I just tried again with "run -Q" from gdb and the result is the same.
> > 24.5 never called sys_rename() and 25.0.91 called sys_rename() with
> > two same names.
> 
> What about Frename_file? does 24.5 call it in this scenario?
> 
> If it doesn't, then please look at the beginning of backup-buffer (in
> files.el), make sure it is called in 24.5 in this scenario, and then
> please tell what are the values of real-file-name and backup-info in
> this part at the beginning of backup-buffer:
> 
> 	(let* ((real-file-name (file-chase-links buffer-file-name))
> 	       (backup-info (find-backup-file-name real-file-name)))
> 
> Also, what are the values of make-backup-files, backup-inhibited, and
> buffer-backed-up in the buffer that visits the read-only file?
> 
> Btw, is that file under some kind of version control, per chance?
> 
> And please make sure, from now on, to test everything in "emacs -Q",
> to prevent any customizations from getting in the way of this
> investigation.

Thanks.

bug#22795: 25.0.91; Can't write read only file on w32

[Glenn Morris]

Eli Zaretskii wrote:

> Not really, no.  I guess we still need the answers to the questions I
> asked back in March, repeated below:

No further response in 6 months, closing.

bug#22795: 25.0.91; Can't write read only file on w32

[Eli Zaretskii]

> Date: Mon, 29 Feb 2016 09:53:54 -0800
> CC: <22795@debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
> 
> > Does the file that Emacs tries to open here, c:\d\ota\memo, exist when
> > _wopen is called, and if so, is it read-only?  Please check this with
> > both versions of Emacs, and see if there's any differences in what
> > happens.
> 
> In both cases the original file exists right before calling _wopen()
> but there is a difference.  On 25.0.91 the file remains read-only but
> on 24.5 the file is writable right before calling _open().  Now we
> have some clue here.

The file shouldn't exist at this point, because Emacs renamed it to a
backup file.  This is what I see here: the first call to _wopen,
without _O_CREAT, fails, and we then call _wopen again with _O_CREAT,
which creates the file.

If during the first call to sys_open the file already exists, then the
problem is not in sys_open, the problem is when the file is backed-up,
which should involve sys_rename.  If you put a breakpoint inside
sys_rename, you should see it called after you type "C-x C-s" to save
the file and answer the question Emacs displays about the file being
write-protected.  Please step through sys_rename_replace and see what
happens there, perhaps the code there fails to detect that the file is
read-only and remove the RO bit before renaming.