GNU bug report logs -
#37884
27.0.50; Cannot write to a file in VirtualBox shared directory
Previous Next
Reported by: Bernardo <bernardo.bacic <at> pobox.com>
Date: Wed, 23 Oct 2019 10:29:01 UTC
Severity: normal
Found in version 27.0.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
Message #23 received at 37884 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Sun, 27 Oct 2019 17:52:39 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Robert Pluim <rpluim <at> gmail.com>
> >> Date: Sun, 27 Oct 2019 16:34:54 +0100
> >> Cc: 37884 <at> debbugs.gnu.org
> >>
> >> 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
This bug report was last modified 5 years and 205 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.