From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains Date: Wed, 30 Jun 2021 16:26:22 +0300 Message-ID: <83k0mbmqkh.fsf@gnu.org> References: <87o8bn7bie.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12337"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ncaprisunfan@gmail.com, 49261@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 30 15:27:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyaFC-0002xu-Q1 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Jun 2021 15:27:10 +0200 Original-Received: from localhost ([::1]:53780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyaFB-0006h9-QZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Jun 2021 09:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyaF5-0006h0-67 for bug-gnu-emacs@gnu.org; Wed, 30 Jun 2021 09:27:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45353) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lyaF4-0007YE-TW for bug-gnu-emacs@gnu.org; Wed, 30 Jun 2021 09:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lyaF4-0003vt-R5 for bug-gnu-emacs@gnu.org; Wed, 30 Jun 2021 09:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jun 2021 13:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49261 X-GNU-PR-Package: emacs Original-Received: via spool by 49261-submit@debbugs.gnu.org id=B49261.162505958715047 (code B ref 49261); Wed, 30 Jun 2021 13:27:02 +0000 Original-Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 13:26:27 +0000 Original-Received: from localhost ([127.0.0.1]:56893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaEV-0003ud-KK for submit@debbugs.gnu.org; Wed, 30 Jun 2021 09:26:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaEU-0003uN-L6 for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 09:26:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38146) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyaEP-00075S-Df; Wed, 30 Jun 2021 09:26:21 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyaEO-0004hM-Hi; Wed, 30 Jun 2021 09:26:21 -0400 In-Reply-To: <87o8bn7bie.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 30 Jun 2021 15:00:41 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209188 Archived-At: > From: Lars Ingebrigtsen > Date: Wed, 30 Jun 2021 15:00:41 +0200 > Cc: 49261@debbugs.gnu.org > > Would it make sense to allow the user to control where the lockfiles are > written? Yes, I think so. But it is not as trivial as it could sound, because... > The lockfiles are symlinks, so it should theoretically be > possible to have them elsewhere without being any racier than the code > currently is, I think. ...even if the lock files are symlinks (which they not necessarily are), we need to handle the case of several files with identical basenames in different directories. (Their being symlinks is unimportant, because the target of the symlink doesn't exist.)