GNU bug report logs - #37884
27.0.50; Cannot write to a file in VirtualBox shared directory

Previous Next

Package: emacs;

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):

From: Bernardo <bernardo.bacic <at> pobox.com>
To: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 37884 <at> debbugs.gnu.org
Subject: Re: bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared
 directory
Date: Mon, 28 Oct 2019 20:23:22 +1100
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.