[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared director
From: |
Robert Pluim |
Subject: |
bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory |
Date: |
Thu, 24 Oct 2019 18:10:59 +0200 |
>>>>> On Wed, 23 Oct 2019 21:28:06 +1100, Bernardo <bernardo.bacic@pobox.com>
>>>>> said:
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("mk7@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, "mk7@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
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Bernardo, 2019/10/23
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory,
Robert Pluim <=
- Message not available
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Robert Pluim, 2019/10/27
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Eli Zaretskii, 2019/10/27
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Robert Pluim, 2019/10/27
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Eli Zaretskii, 2019/10/27
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Bernardo, 2019/10/28
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Robert Pluim, 2019/10/28
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Bernardo, 2019/10/29
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Andreas Schwab, 2019/10/29
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Robert Pluim, 2019/10/29
- bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory, Bernardo, 2019/10/30