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.devel Subject: Re: How to stop desktop.lock file creation Date: Sun, 27 Mar 2022 08:03:14 +0300 Message-ID: <83leww9ect.fsf@gnu.org> References: <1843424395.177680.1648161239137@mail1.libero.it> <838rsyczh6.fsf@gnu.org> <1960767723.287175.1648248799870@mail1.libero.it> <83ils1b6x2.fsf@gnu.org> <1611306500.320421.1648330200906@mail1.libero.it> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5257"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Angelo Graziosi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 27 07:04:20 2022 Return-path: Envelope-to: ged-emacs-devel@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 1nYL4e-0001AR-8X for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Mar 2022 07:04:20 +0200 Original-Received: from localhost ([::1]:42176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nYL4c-0006me-Um for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Mar 2022 01:04:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYL3c-000638-Sr for emacs-devel@gnu.org; Sun, 27 Mar 2022 01:03:16 -0400 Original-Received: from [2001:470:142:3::e] (port=37846 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYL3c-0007yT-Cq; Sun, 27 Mar 2022 01:03:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ALUl+3aAS0TMukscMhzHso/e4X3GMsaGkD+9lHfLoTc=; b=m50u2dnZyibE h0gZZquy90IqKmCjvhXLQSMwoxAXfJxe3xzhBb3M8kLi+T/tSoxhJG0lphhcA55lyD5Vrv1OgTYL6 ZYKqt4/GotIvU4HuZX0852hG4ztcJEMkO2tSwOyRlcn1/vTuxoy3efxao5x+j5mXpnUhB3DajFsyE 4xSSsSD7oDYPe2T+1RhxlvUDbSpnDP/vgYBBAgz8wfwYMH/HRSEStSgLQd3EFlLshQS4pXtSyekg2 Xl5LlT1VOVa+QIcZGTgmmOwsryC/vbKuwwqOSU5G9NyQJm/d5PF3YcIlUtzJYa4DJ/Cv2W0h7ERX6 GuvcqZKR2fR3UBULVRL30A==; Original-Received: from [87.69.77.57] (port=3425 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 1nYL3b-0001DL-Rz; Sun, 27 Mar 2022 01:03:16 -0400 In-Reply-To: <1611306500.320421.1648330200906@mail1.libero.it> (message from Angelo Graziosi on Sat, 26 Mar 2022 22:30:00 +0100 (CET)) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:287496 Archived-At: > Date: Sat, 26 Mar 2022 22:30:00 +0100 (CET) > From: Angelo Graziosi > Cc: emacs-devel@gnu.org > > > You don't need to play this game. If you set > > desktop-load-locked-desktop to t, Emacs will unconditionally load the > > desktop even if locked, no questions asked. Its effect is the same as > > not having the lock at all, when the process which locked the desktop > > no longer runs. > > When Emacs ask for loading the desktop file it says > > "Warning: desktop file appears to be in use by PID xyza. > Using it may cause conflicts. Use it anyway? (y or n)" > > So, _if it says that could be conflicts_, in my opinion, the best way to go is to accept it, close Emacs, restart Emacs, so that it starts in a clean state. What it wants to say that it doesn't know whether the process that locked the desktop file is still running. If it is still running, then yes, using this file in two Emacs processes could cause conflicts. And please note that the process which locked it could run on another computer. If that process is not running, there could be no conflicts, and it is safe to answer "y". > Why I have to to all this? Really I need this? or should I accept with the risk of conflicts (i am sure they do not occur!)? You should verify (or in your case know in advance) that the locking Emacs process no longer runs. > > > Emacs worked the same before its introduction... > > > > The lock was introduced in Emacs 22.2, quite some time ago. It isn't > > a new feature. > > I know this and it is what I did mean. > > If users could live without the lock file until version 22 why can't they live without it with the current version? The lock was introduced to handle the cases in which users did encounter conflicts by using the same desktop file from two or more Emacs processes. See https://lists.gnu.org/archive/html/emacs-devel/2006-04/msg01253.html > In short: really we need this lock file? Yes, IMO. > really it is useful in all situations? It is a safety net that is definitely useful in some situations. As any safety net, it can sometimes produce false positives, and we are working on making those more rare. For example, Emacs 29 will have an additional value of desktop-load-locked-desktop that will be capable of taking the lock silently if it was locked by a local process that is no longer running. > Why not adding a flag to avoid its creation and that the user sets at its own risk? Because we think desktop-load-locked-desktop is that flag.