bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory

[Bernardo]

Emacs built from Git repository (21-Oct-2019) is running in a Virtual
Box virtual machine.
The guest operating system (VM) where Emacs is running is Debian
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch

The host operating system is Windows 10 Enterprise, version 1709, build
16299.1451.
VirtualBox version is 6.0.14

1. Start emacs with -Q command line option
2 Run command:
M-: (setq debug-on-error t) RET
to see error details
3. Use C-x C-f to open /media/sf_Home/zz_stuff - a text file within
Virtual Box shared directory.
The user has read/write privileges on the file. Also, file can be
modified without problems in other editors.
4. Modify the file and save it with C-x C-s
5. The save operation fails and the stack shows:
Debugger entered--Lisp error: (file-error "Unlocking file" "Operation not permitted" "/media/sf_Home/zz_stuff")
write-region(nil nil "/home/mk7/zz_stuff" nil t "/media/sf_Home/zz_stuff")
basic-save-buffer-2()
basic-save-buffer-1()
basic-save-buffer(t)
save-buffer(1)
funcall-interactively(save-buffer 1)
call-interactively(save-buffer nil nil)
command-execute(save-buffer)


When Emacs is started with strace ( $ strace emacs -Q ) it can be seen
that there are issues with the lock file that's created -
/media/sf_Home/.#zz_stuff

The strace messages are in the attachement.

The 'shared directory' is a feature of Virtual Box which allows both the
host and applications running in a virtual machine to have access to
files in the same directory.

The file system type of the shared directory is vboxsf which seems to be
a layer on top of NTFS.
$ mount | grep vbox
Home on /media/sf_Home type vboxsf (rw,nodev,relatime,<snip>

It looks like symbolic links are not allowed on
this FS type; from terminal:
$ ln -s zz_stuff my_link
ln: failed to create symbolic link 'my_link': Operation not permitted

Appears Emacs doesn't detect a symlink cannot be created on this file
system
https://www.gnu.org/software/emacs/manual/html_node/emacs/Interlocking.html
"[1] If your file system does not support symbolic links, a regular file is used."


The old version of Emacs installed using Debian package manager doesn't
have this issue - it can write to the same file without
problems. However I couldn't see a 'lock file' in the directory where
the edited file is located. It appears in this case the lock file is
created elsewhere (possibly .emacs.d directory) in the native (ext4)
file system.
This old Emacs version is
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-09-12 on hullmann, modified by Debian




In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
of 2019-10-21 built on deb
Repository revision: 30deac84c4168a6315a08a0dd85f6dde9b9df439
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
value of $LC_COLLATE: C
value of $LANG: en_AU.UTF-8
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-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
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors 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 composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray 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 threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 43885 6288)
(symbols 48 5994 1)
(strings 32 15356 1694)
(string-bytes 1 501149)
(vectors 16 9174)
(vector-slots 8 123172 10012)
(floats 8 20 37)
(intervals 56 183 0)
(buffers 1000 11))

[Robert Pluim]

Bernardo> When Emacs is started with strace ( $ strace emacs -Q ) it can be seen
Bernardo> that there are issues with the lock file that's created -
Bernardo> /media/sf_Home/.#zz_stuff

Bernardo> The strace messages are in the attachement.

Weʼre getting EPERM when doing unlink on the lock file, which is very
strange.

Bernardo> The 'shared directory' is a feature of Virtual Box which allows both the
Bernardo> host and applications running in a virtual machine to have access to
Bernardo> files in the same directory.

Bernardo> The file system type of the shared directory is vboxsf which seems to be
Bernardo> a layer on top of NTFS.
Bernardo> $ mount | grep vbox
Bernardo> Home on /media/sf_Home type vboxsf (rw,nodev,relatime,<snip>

Bernardo> It looks like symbolic links are not allowed on
Bernardo> this FS type; from terminal:
Bernardo> $ ln -s zz_stuff my_link
Bernardo> ln: failed to create symbolic link 'my_link': Operation not permitted

Right, so emacs switches to a regular file instead:

symlink fails:
symlink("***@deb.2246:1571819801", "/media/sf_Home/.#zz_stuff") = -1 EPERM (Operation not permitted)

so use a regular file:

open("/media/sf_Home/.#-emacsvxLcB2", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 13

and put the lock information inside the file, and make it read-only:

write(13, "***@deb.2246:1571819801", 23) = 23
fchmod(13, 0444) = 0

and then rename it:

"/media/sf_Home/.#zz_stuff", RENAME_NOREPLACE) = 0

Later on when emacs saves the file, it tries to get rid of the lock
file, which fails:

unlink("/media/sf_Home/.#zz_stuff") = -1 EPERM (Operation not permitted)

So your filesystem doesnʼt let you call unlink() on read-only files? I
guess we could try adjusting the chmod to 664 or similar if that helps here.

Robert

[Robert Pluim]

Bernardo> Hi Robert,

Bernardo> apologies for the late response, i came down with a cold and wasn't
Bernardo> checking my email;

No worries.

Bernardo> i have a quick and dirty test along these lines (+ include headers)
Bernardo> emulating what's happening when a lock is created/removed.
Bernardo> ,----
Bernardo> | int main()
Bernardo> | {
Bernardo> | const char buff[] = "abc";
Bernardo> |
Bernardo> | int fd = open( "another_test", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600);
Bernardo> | write( fd , buff, 3 );
Bernardo> | fchmod( fd, 0444 );
Bernardo> | close( fd );
Bernardo> | unlink( "another_test" );
Bernardo> | return 0;
Bernardo> | }
Bernardo> `----

Bernardo> as you would expect works fine here (at home) on ext4 file system;
Bernardo> will try this on work computer (most likely tomorrow) where VirtualBox
Bernardo> is installed, possibly tweak the file access flags and report the
Bernardo> results back;

Thanks. I might have a VirtualBox instance lying around, but itʼs
hosted on GNU/Linux, not Windows, so the behaviour is likely to be
different.

Bernardo> thanks for looking into this

Youʼre welcome.

Eli, if the results come back that using 0664 or similar on lockfiles
resolves this, would you be amenable to such a change?

Robert

[Eli Zaretskii]

Date: Sun, 27 Oct 2019 16:34:54 +0100
Eli, if the results come back that using 0664 or similar on lockfiles
resolves this, would you be amenable to such a change?

I'm not sure I understand the proposal. Is the suggestion to chmod
the file to 0644 before calling unlink? Or is the suggestion
something else?

[Robert Pluim]

Date: Sun, 27 Oct 2019 16:34:54 +0100
Eli, if the results come back that using 0664 or similar on lockfiles
resolves this, would you be amenable to such a change?

Eli> I'm not sure I understand the proposal. Is the suggestion to chmod
Eli> the file to 0644 before calling unlink?

Yes, although of course this is assuming it works, one other option
could be to just not mess with the file's permissions at all when
initially creating the lockfile.

Robert

[Eli Zaretskii]

Date: Sun, 27 Oct 2019 17:01:11 +0100

Post by Robert Pluim
Eli, if the results come back that using 0664 or similar on lockfiles
resolves this, would you be amenable to such a change?

Eli> I'm not sure I understand the proposal. Is the suggestion to chmod
Eli> the file to 0644 before calling unlink?
Yes, although of course this is assuming it works, one other option
could be to just not mess with the file's permissions at all when
initially creating the lockfile.

AFAIU, the problem is with removing the file? If so, I'd suggest to
do what w32.c does: call unlink as we do now, and if it fails, call
chmod to make it writable and try unlink again. This has an advantage
of not changing anything for filesystems that implement the Posix
semantics.

[Bernardo]

Post by Robert Pluim

Date: Sun, 27 Oct 2019 16:34:54 +0100
Eli, if the results come back that using 0664 or similar on lockfiles
resolves this, would you be amenable to such a change?

Eli> I'm not sure I understand the proposal. Is the suggestion to chmod
Eli> the file to 0644 before calling unlink?
Yes, although of course this is assuming it works, one other option
could be to just not mess with the file's permissions at all when
initially creating the lockfile.

Hi Robert,

what you suggested (changing file mode) works fine; I haven't
investigated Eli's suggestion (w32.c)

in the end my test code looked like this (sans the headers)
int main()
{
const char buff[] = "abc";
int result = 0;

int fd = open( "another_test", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600);
result = write( fd , buff, 3 );
printf( "write returned %d\n", result );
result = fchmod( fd, 0444 );
printf( "fchmod returned %d\n", result );
close( fd );
result = unlink( "another_test" );
printf( "unlink returned %d\n", result );
return 0;
}


and the output was:
write returned 3
fchmod returned 0
unlink returned -1

and when the file access mode was changed to 0644:
write returned 3
fchmod returned 0
unlink returned 0

and the lock file was removed successfully;

Afterwards, i modified a file in Emacs source tree like so:

$ git diff src/filelock.c
diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..79eb8fa91e 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -403,7 +403,7 @@ create_lock_file (char *lfname, char *lock_info_str, bool force)
lock_info_len = strlen (lock_info_str);
err = 0;
if (emacs_write (fd, lock_info_str, lock_info_len) != lock_info_len
- || fchmod (fd, S_IRUSR | S_IRGRP | S_IROTH) != 0)
+ || fchmod (fd, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) != 0)
err = errno;
/* There is no need to call fsync here, as the contents of
the lock file need not survive system crashes. */

and Emacs is happy again, no problems with writing to files in
VirtualBox shared directory.

Please let me know if you want me to test anything else.

--
Cheers, Bernardo

[Robert Pluim]

Bernardo> $ git diff src/filelock.c
Bernardo> diff --git a/src/filelock.c b/src/filelock.c
Bernardo> index ff25d6475d..79eb8fa91e 100644
Bernardo> --- a/src/filelock.c
Bernardo> +++ b/src/filelock.c
Bernardo> @@ -403,7 +403,7 @@ create_lock_file (char *lfname, char *lock_info_str, bool force)
Bernardo> lock_info_len = strlen (lock_info_str);
Bernardo> err = 0;
Bernardo> if (emacs_write (fd, lock_info_str, lock_info_len) != lock_info_len
Bernardo> - || fchmod (fd, S_IRUSR | S_IRGRP | S_IROTH) != 0)
Bernardo> + || fchmod (fd, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) != 0)
Bernardo> err = errno;
Bernardo> /* There is no need to call fsync here, as the contents of
Bernardo> the lock file need not survive system crashes. */

Bernardo> and Emacs is happy again, no problems with writing to files in
Bernardo> VirtualBox shared directory.

Bernardo> Please let me know if you want me to test anything else.

I think Eli's suggestion was more like the below, which only calls
fchmod if the unlink fails.

diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..7fb14774b0 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -732,6 +732,15 @@ unlock_file (Lisp_Object fn)
int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
err = errno;
+ /* On certain filesystems the file must be writable for unlink to
+ succeed (Bug#37784). */
+ if (errno == EPERM)
+ {
+ fchmod (fd, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ errno = 0;
+ if (unlink (lfname) != 0 && errno != ENOENT)
+ err = errno;
+ }
if (0 < err)
report_file_errno ("Unlocking file", filename, err);

[Bernardo]

Post by Robert Pluim
Bernardo> $ git diff src/filelock.c
Bernardo> diff --git a/src/filelock.c b/src/filelock.c
Bernardo> index ff25d6475d..79eb8fa91e 100644
Bernardo> --- a/src/filelock.c
Bernardo> +++ b/src/filelock.c
Bernardo> lock_info_len = strlen (lock_info_str);
Bernardo> err = 0;
Bernardo> if (emacs_write (fd, lock_info_str, lock_info_len) != lock_info_len
Bernardo> - || fchmod (fd, S_IRUSR | S_IRGRP | S_IROTH) != 0)
Bernardo> + || fchmod (fd, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) != 0)
Bernardo> err = errno;
Bernardo> /* There is no need to call fsync here, as the contents of
Bernardo> the lock file need not survive system crashes. */
Bernardo> and Emacs is happy again, no problems with writing to files in
Bernardo> VirtualBox shared directory.
Bernardo> Please let me know if you want me to test anything else.
I think Eli's suggestion was more like the below, which only calls
fchmod if the unlink fails.
diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..7fb14774b0 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -732,6 +732,15 @@ unlock_file (Lisp_Object fn)
int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
err = errno;
+ /* On certain filesystems the file must be writable for unlink to
+ succeed (Bug#37784). */
+ if (errno == EPERM)
+ {
+ fchmod (fd, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ errno = 0;
+ if (unlink (lfname) != 0 && errno != ENOENT)
+ err = errno;
+ }
if (0 < err)
report_file_errno ("Unlocking file", filename, err);

two changes in that code snippet were needed to get things working:
* replace fchmod() with chmod() (a minor one)
* more importantly, had to set the value of err to 0, otherwise
it would end up with the same problem;

guess you'll have a closer look at the 2nd change and possibly come up
with a better solution

The code that works fine looks like this:

$ git diff
diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..046a1b014f 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -732,6 +732,16 @@ unlock_file (Lisp_Object fn)
int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
err = errno;
+ /* On certain filesystems the file must be writable for unlink to
+ succeed (Bug#37784). */
+ if (errno == EPERM)
+ {
+ chmod (lfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ err = 0;
+ errno = 0;
+ if (unlink (lfname) != 0 && errno != ENOENT)
+ err = errno;
+ }
if (0 < err)
report_file_errno ("Unlocking file", filename, err);

[Andreas Schwab]

Post by Bernardo
diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..046a1b014f 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -732,6 +732,16 @@ unlock_file (Lisp_Object fn)
int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
err = errno;
+ /* On certain filesystems the file must be writable for unlink to
+ succeed (Bug#37784). */
+ if (errno == EPERM)

You need to move this check under the condition above, otherwise you may
get a false positive if unlink didn't fail or wasn't called at all.

Post by Bernardo
+ {
+ chmod (lfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ err = 0;
+ errno = 0;

No need to clear errno here.

Post by Bernardo
+ if (unlink (lfname) != 0 && errno != ENOENT)
+ err = errno;
+ }

Andreas.

[Robert Pluim]

Andreas> You need to move this check under the condition above, otherwise you may
Andreas> get a false positive if unlink didn't fail or wasn't called at all.

Post by Robert Pluim
+ {
+ chmod (lfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ err = 0;
+ errno = 0;

Indeed. Next time maybe Iʼll try actually compiling my patches before
I send them. Take 3

diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..bd1e8d9b2d 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -731,9 +731,20 @@ unlock_file (Lisp_Object fn)

int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
+ {
err = errno;
- if (0 < err)
- report_file_errno ("Unlocking file", filename, err);
+ /* On certain filesystems the file must be writable for unlink to
+ succeed, so make it writable and retry (Bug#37784). */
+ if (errno == EPERM)
+ {
+ chmod (lfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ err = 0;
+ if (unlink (lfname) != 0 && errno != ENOENT)
+ err = errno;
+ }
+ }
+ if (0 < err)
+ report_file_errno ("Unlocking file", filename, err);

SAFE_FREE ();
}

[Bernardo]

Post by Robert Pluim
Andreas> You need to move this check under the condition above, otherwise you may
Andreas> get a false positive if unlink didn't fail or wasn't called at all.

Post by Robert Pluim
+ {
+ chmod (lfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ err = 0;
+ errno = 0;

Indeed. Next time maybe Iʼll try actually compiling my patches before
I send them. Take 3
diff --git a/src/filelock.c b/src/filelock.c
index ff25d6475d..bd1e8d9b2d 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -731,9 +731,20 @@ unlock_file (Lisp_Object fn)
int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
+ {
err = errno;
- if (0 < err)
- report_file_errno ("Unlocking file", filename, err);
+ /* On certain filesystems the file must be writable for unlink to
+ succeed, so make it writable and retry (Bug#37784). */
+ if (errno == EPERM)
+ {
+ chmod (lfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ err = 0;
+ if (unlink (lfname) != 0 && errno != ENOENT)
+ err = errno;
+ }
+ }
+ if (0 < err)
+ report_file_errno ("Unlocking file", filename, err);
SAFE_FREE ();
}

confirmed this patch works fine;
thanks for the effort (and persistence)

[Robert Pluim]

Bernardo> confirmed this patch works fine;
Bernardo> thanks for the effort (and persistence)

Thanks for testing. Eli, Andreas, let me know of any further issues,
otherwise Iʼll push in the next couple of days.

Thanks

Robert

[Eli Zaretskii]

Date: Wed, 30 Oct 2019 14:31:30 +0100
Bernardo> confirmed this patch works fine;
Bernardo> thanks for the effort (and persistence)
Thanks for testing. Eli, Andreas, let me know of any further issues,
otherwise Iʼll push in the next couple of days.

Thanks. I'd like to hear Paul's opinion on this change. Paul, do you
see any downsides to the last change posted in this discussion? IOW,
could there be some situations where it could do any harm?

TIA

[Paul Eggert]

Post by Eli Zaretskii
Paul, do you
see any downsides to the last change posted in this discussion? IOW,
could there be some situations where it could do any harm?

That change involves two extra system calls (one of which doesn't check
the return value?!). In contrast, Bernardo's suggestion is simpler,
involves no extra system calls (or machine instructions, for that
matter), and has been tested. So I installed the attached patch to
implement and document the workaround, and am optimistically closing the
bug report.

The underlying problem is a significant bug in Virtual Box atop Windows
10 Enterprise, a bug that surely breaks other applications (and could
well break other parts of Emacs) that assume one can unlink a readonly
file. Apparently the bug has been known for some time and a fix is
available but the VirtualBox folks haven't gotten around to installing
the fix:

https://www.virtualbox.org/ticket/4890
https://www.virtualbox.org/ticket/16463

If you're a VirtualBox user, I suggest that you ping the developers
about fixing this, as one can't reasonably expect every application
developer to work around their bug.

[Robert Pluim]

Post by Eli Zaretskii
Paul, do you
see any downsides to the last change posted in this discussion? IOW,
could there be some situations where it could do any harm?

Paul> That change involves two extra system calls (one of which doesn't
Paul> check the return value?!).

I donʼt know what value there would be in checking the return value of
chmod, given that weʼre already in an error situation.

Paul> In contrast, Bernardo's suggestion is
Paul> simpler, involves no extra system calls (or machine instructions, for
Paul> that matter), and has been tested. So I installed the attached patch
Paul> to implement and document the workaround, and am optimistically
Paul> closing the bug report.

Looks good to me. I was trying to avoid that, since I thought there
was a strong desire to keep the file read-only, otherwise why bother
with the fchmod in the first place?

Robert

[Eli Zaretskii]

Date: Thu, 31 Oct 2019 08:38:59 +0100
Paul> In contrast, Bernardo's suggestion is
Paul> simpler, involves no extra system calls (or machine instructions, for
Paul> that matter), and has been tested. So I installed the attached patch
Paul> to implement and document the workaround, and am optimistically
Paul> closing the bug report.
Looks good to me. I was trying to avoid that, since I thought there
was a strong desire to keep the file read-only, otherwise why bother
with the fchmod in the first place?

Exactly my line of reasoning.

But if there's no special reason to have that file unwritable, then a
simpler change is of course better.

[Paul Eggert]

Post by Robert Pluim
I thought there
was a strong desire to keep the file read-only, otherwise why bother
with the fchmod in the first place?

The desire was quite weak, not strong. I put in that fchmod in commit
2013-03-05T22:35:41!***@cs.ucla.edu only because mkostemp creates the
lock file with mode 0600 but we want the file world-readable and so
Emacs must OR 0044 into the mode. At the time, I thought there was no
reason to have the file be writable to anybody once written, so I
fchmod'ed it to 0444. But Bug#37884 means the file should be
user-writable (to work around the compatibility issue with the
nonstandard filesystem), so fchmod'ing to 0644 is a better choice.