From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Bernardo Newsgroups: gmane.emacs.bugs Subject: bug#37884: 27.0.50; Cannot write to a file in VirtualBox shared directory Date: Mon, 28 Oct 2019 20:23:22 +1100 Message-ID: <874kztdy0l.fsf@pobox.com> References: <87h83zeoy1.fsf@pobox.com> <87blu2emi3.fsf@pobox.com> <83lft6rxrs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="200871"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 37884@debbugs.gnu.org To: Robert Pluim , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 28 10:24:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iP1G1-000q4n-KW for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Oct 2019 10:24:13 +0100 Original-Received: from localhost ([::1]:52074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iP1Fz-0000fc-SN for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Oct 2019 05:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59251) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iP1Ft-0000fD-9K for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2019 05:24:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iP1Fs-0001Nc-7y for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2019 05:24:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35001) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iP1Fs-0001NW-4o for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2019 05:24:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iP1Fq-0001Na-7I for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2019 05:24:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bernardo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Oct 2019 09:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37884 X-GNU-PR-Package: emacs Original-Received: via spool by 37884-submit@debbugs.gnu.org id=B37884.15722546155268 (code B ref 37884); Mon, 28 Oct 2019 09:24:02 +0000 Original-Received: (at 37884) by debbugs.gnu.org; 28 Oct 2019 09:23:35 +0000 Original-Received: from localhost ([127.0.0.1]:43822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iP1FM-0001Ms-PJ for submit@debbugs.gnu.org; Mon, 28 Oct 2019 05:23:35 -0400 Original-Received: from pecan-mail.exetel.com.au ([220.233.0.8]:56325 helo=pecan.exetel.com.au) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iP1FK-0001Mc-Jl for 37884@debbugs.gnu.org; Mon, 28 Oct 2019 05:23:31 -0400 Original-Received: from 105.199.233.220.static.exetel.com.au ([220.233.199.105] helo=deb) by pecan.exetel.com.au with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1iP1FC-00008e-VA; Mon, 28 Oct 2019 20:23:22 +1100 In-Reply-To: (Robert Pluim's message of "Sun, 27 Oct 2019 17:01:11 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170287 Archived-At: Robert Pluim writes: >>>>>> On Sun, 27 Oct 2019 17:52:39 +0200, Eli Zaretskii said: > > >> From: Robert Pluim > >> Date: Sun, 27 Oct 2019 16:34:54 +0100 > >> Cc: 37884@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