GNU bug report logs - #22795
25.0.91; Can't write read only file on w32

Previous Next

Package: emacs;

Reported by: "Ota, Takaaki" <Takaaki.Ota <at> am.sony.com>

Date: Wed, 24 Feb 2016 18:18:02 UTC

Severity: normal

Tags: moreinfo

Found in version 25.0.91

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #34 received at 22795 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Ota\, Takaaki" <Takaaki.Ota <at> am.sony.com>
Cc: 22795 <at> debbugs.gnu.org
Subject: Re: bug#22795: 25.0.91; Can't write read only file on w32
Date: Fri, 26 Feb 2016 23:53:33 +0200
> Date: Fri, 26 Feb 2016 11:26:05 -0800
> CC: <22795 <at> debbugs.gnu.org>
> From: "Ota, Takaaki" <Takaaki.Ota <at> 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.




This bug report was last modified 8 years and 163 days ago.

Previous Next


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