From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Duncan Greatwood Newsgroups: gmane.emacs.bugs Subject: bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock Date: Thu, 16 May 2024 12:27:05 -0700 Message-ID: References: <867cfujge6.fsf@gnu.org> <86fruhiwt0.fsf@gnu.org> <868r09ivqn.fsf@gnu.org> <867cftiprt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000156014061897394d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10631"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70973@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 16 21:29:32 2024 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 1s7gnD-0002WW-E2 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 May 2024 21:29:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s7gmk-0001Qk-6w; Thu, 16 May 2024 15:29:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s7gmi-0001QX-PJ for bug-gnu-emacs@gnu.org; Thu, 16 May 2024 15:29:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s7gmi-0005nQ-H1 for bug-gnu-emacs@gnu.org; Thu, 16 May 2024 15:29:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s7gmk-0002on-JI for bug-gnu-emacs@gnu.org; Thu, 16 May 2024 15:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Duncan Greatwood Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 May 2024 19:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70973 X-GNU-PR-Package: emacs Original-Received: via spool by 70973-submit@debbugs.gnu.org id=B70973.171588771310825 (code B ref 70973); Thu, 16 May 2024 19:29:02 +0000 Original-Received: (at 70973) by debbugs.gnu.org; 16 May 2024 19:28:33 +0000 Original-Received: from localhost ([127.0.0.1]:50531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7gmG-0002oX-Eu for submit@debbugs.gnu.org; Thu, 16 May 2024 15:28:33 -0400 Original-Received: from mail-lf1-f42.google.com ([209.85.167.42]:60751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7gmC-0002oN-70 for 70973@debbugs.gnu.org; Thu, 16 May 2024 15:28:31 -0400 Original-Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-52327368e59so1236828e87.1 for <70973@debbugs.gnu.org>; Thu, 16 May 2024 12:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715887639; x=1716492439; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KgP6gN85SbRHk2GSv67ihbPiT0GTtpzGQQYZgt84jCw=; b=c1TSA5fPzNhg0/oBJb5MqQk/LTzGgFxxeP66bI3a/XvawgLCtLFO3BuEEG805lJpJd KqWncg7nSBXGl0LgsQQ+Iv3y0Peg5+1nQsePEW9MMIxRhZdlpptubkM1uxuPY8VVbl9N bCwB2R22ieYl6aXLzMhWbhoVo8oWu5nFB2O6um255v5u3JapcztGkMcYjaNZb2Fa8PmD whqganMG7kOkmgRlN+CvZvGAhPd6xqVceCnruiR3GRaU0aZ0suPPmZNaTPo/szMsrkMz ObJQlk5y3vxbbdSZyMlskTrcggkfx3IqelsUoEBVuGqeHhIXeME5rbFDQBdv4BWdyF+P PKyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715887639; x=1716492439; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KgP6gN85SbRHk2GSv67ihbPiT0GTtpzGQQYZgt84jCw=; b=f2nhUSb9kNIBgpj5wT8lTXiwc+cFgU+QpqtHRPloyPhzupeNKl3Bol0fGJvnzWpgDM /wtAPDYZZWSJ4eQBbkArXBW00N9dCzAwSjqH0jlTDD67KfSCinGVrcSHiKnlHRFxgJ1Z KtvkB+/qvSATNgRXgmRL3f3NKaFxfCFs8ksayIj5RTZW7Wi0zvAKATJnQwCRximZhsLW 416uQA8GiX+pNOyMq4DvydWLe5KzE2D0+ZZwRjyCpDwGxdZnZ3YMIdCxg9CYnjvW6DMB E/E5ZGoQGfD0CM3eE27MmlcK+lSQrAxv4LmcsSiy3rU7326YaPFbs4BK3QdB7s+FS8se Ty0A== X-Gm-Message-State: AOJu0YzspcMci2bZWIGOQ3zuSQWzuuXjfk5kcRrUnYRxoajaPfgVyQfn xEpOOVe/CpT9MPgic6qV/aX3InKGOjsqt7ZAeBoPiW7yPz7S3gEGayKALdQ1Hu4= X-Google-Smtp-Source: AGHT+IEMhtOa0LirESwIKHAId+g5guZDrHBYP2mvSVVOxhlCjXdo4BjQKU5eiZBaklJjlBdVvsWsgQ== X-Received: by 2002:ac2:596a:0:b0:523:a5b3:5e1d with SMTP id 2adb3069b0e04-523a5b35f2amr3089126e87.10.1715887638387; Thu, 16 May 2024 12:27:18 -0700 (PDT) Original-Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-521f38d340dsm3060579e87.175.2024.05.16.12.27.17 for <70973@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 May 2024 12:27:17 -0700 (PDT) Original-Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2e6792ea67fso15078571fa.1 for <70973@debbugs.gnu.org>; Thu, 16 May 2024 12:27:17 -0700 (PDT) X-Received: by 2002:a2e:22c6:0:b0:2e0:eb96:7b53 with SMTP id 38308e7fff4ca-2e5205ec950mr114680741fa.44.1715887637084; Thu, 16 May 2024 12:27:17 -0700 (PDT) In-Reply-To: <867cftiprt.fsf@gnu.org> X-Gmail-Original-Message-ID: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:285193 Archived-At: --000000000000156014061897394d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> Emacs does not create lock files that are symlinks AFAIK. >That is not true. lock files are normally dangling symlinks, >i.e. their target does not exist. Ah, I see. I just tried editing a different file, client.cc, causing a lockfile to be created. Sure enough, just as you say, that lockfile is a dangling symlink: ls -al .#client.cc lrwxr-xr-x@ 1 username staff 40 May 16 11:39 .#client.cc -> username@DMG-MB-Air-15-2024.local.3071 Then, returning to editing ~/.emacs (which, being a symlink, is actually editing ~/Dropbox/Documents/Projects/emacs/dotemacs). Again, this creates a dangling symlink as you would expect: ls -l .#dotemacs lrwxr-xr-x@ 1 username staff 40 May 16 11:43 .#dotemacs -> username@DMG-MB-Air-15-2024.local.3071 At this point, I tried doing a hard reboot (power cycle) to simulate the kernel crash I mentioned before. But (not surprisingly) after the reboot the lock file still looks as you would expect. ls -l .#dotemacs lrwxr-xr-x@ 1 username staff 40 May 16 11:43 .#dotemacs -> username@DMG-MB-Air-15-2024.local.3071 Noting that, in the bad case, the lock file was not only *not* a dangling symlink as it should be, but was also of zero size, I would speculate that the kernel crash happened right as emacs was part way through writing the lockfile to disk. Taking a quick look at the emacs source, the C function create_lock_file calls emacs_symlink which in turn calls the OS function symlink. The OS function symlink is commonly assumed to be atomic I believe (e.g. see https://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html). However in this case I would suspect that *the kernel crash terminated the symlink write before it could fully complete*. To fix, perhaps emacs needs to check purported lock files and handle the case where they are not symlinks and/or are of zero size, avoiding the need to remove the partially-written lock file manually. On Thu, May 16, 2024 at 11:18=E2=80=AFAM Eli Zaretskii wrote= : > > From: Duncan Greatwood > > Date: Thu, 16 May 2024 09:20:46 -0700 > > Cc: 70973@debbugs.gnu.org > > > > AFAIK, there is nothing about the symlink that is macOS or DropBox > specific. > > > > Again, ~/.emacs is a symlink to the file in the subfolder of ~/Dropbox. > > > > The lock file is not a symlink. > > > > Emacs does not create lock files that are symlinks AFAIK. > > That is not true. lock files are normally dangling symlinks, > i.e. their target does not exist. On a few systems where lock files > are not symlinks (I knew about only one: MS-Windows), lock files are > regular files, but then they are not empty. And your reports indicate > that it is a regular and empty file: > > > As follows: > > $ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs > > -rw-r--r--@ 1 username staff 0 May 16 07:13 > /Users/username/Dropbox/Documents/Projects/emacs/.#dotemacs > > This is unusual, because it means the information that a lock file > should record: the user and the process ID that locked the file -- is > not recorded anywhere. It is usually recorded either in the name of > the symlink's target or (if the lock file is a regular file) in the > file's contents. > > So something here is not "normal". If indeed on macOS lock files are > not symlinks, they should be regular files which are not empty. If > you could step with a debugger through the code of the C function > create_lock_file and see what happens there when Emacs locks a file > you edit, we could make some progress in investigating this bug. > --=20 NOTICE: This email and its attachments may contain privileged and=20 confidential information, only for the viewing and use of the intended=20 recipient. If you are not the intended recipient, you are hereby notified= =20 that any disclosure, copying, distribution, acting upon, or use of the=20 information contained in this email and its attachments is strictly=20 prohibited and that this email and its attachments must be immediately=20 returned to the sender and deleted from your system. If you received this= =20 email erroneously, please notify the sender immediately.=C2=A0 Xage Securit= y,=20 Inc. and its affiliates will never request personal information (e.g.,=20 passwords, Social Security numbers) via email.=C2=A0 Report suspicious emai= ls to=20 security-alerts@xage.com --000000000000156014061897394d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> Emacs does not= create lock files that are symlinks AFAIK.
>That is not true.= =C2=A0 lock files are normally dangling symlinks,
>i.e. their target = does not exist.

Ah, I see.

= I just tried editing a different file, client.cc, causing a lockfile to be = created. Sure enough, just as you say, that lockfile is a dangling symlink:=
ls -al .#client.cc
lrwxr-xr-x@ 1 username =C2=A0staff =C2=A04= 0 May 16 11:39 .#client.cc -> username@DMG-MB-Air-15-2024.local.3071
=

Then, returning to editing ~/.emacs (which, being= a symlink, is actually editing ~/Dropbox/Documents/Projects/emacs/dotemacs= ).
Again, this creates a dangling symlink as you would expect:
ls -l .#dotemacs
lrwxr-xr-x@ 1 username =C2=A0staff =C2=A040 May= 16 11:43 .#dotemacs -> username@DMG-MB-Air-15-2024.local.3071
=

At this point, I tried doing a hard reboot (power cycle= ) to simulate the kernel crash I mentioned before. But (not surprisingly) a= fter the reboot the lock file still looks as you would expect.
ls= -l .#dotemacs
lrwxr-xr-x@ 1 username =C2=A0staff =C2=A040 May 16 11:43 = .#dotemacs -> username@DMG-MB-Air-15-2024.local.3071

<= /div>
Noting that, in the bad case, the lock file was not only not=C2=A0a dangling symlink as it should be, but was also of zero size, I wo= uld speculate that the kernel crash happened right as emacs was part way th= rough writing the lockfile to disk.

Taking a quick= look at the emacs source, the C function create_lock_file calls=C2=A0emacs= _symlink which in turn calls the OS function=C2=A0symlink.=C2=A0
=
The OS function symlink is commonly assumed to be atomic I b= elieve (e.g. see=C2=A0https://rcrowley.org/2010/01/06/things-unix-can-d= o-atomically.html). However in this case I would suspect that the ke= rnel crash terminated the symlink write before it could fully complete.=

To fix, perhaps emacs needs to check purported lo= ck files and handle the case where they are not symlinks and/or are of zero= size, avoiding the need to remove the partially-written lock file manually= .




On Thu, May 16, 2024 at= 11:18=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 09:20:46 -0700
> Cc: 70973@d= ebbugs.gnu.org
>
> AFAIK, there is nothing about the symlink that is macOS or DropBox spe= cific.
>
> Again, ~/.emacs is a symlink to the file in the subfolder of ~/Dropbox= .
>
> The lock file is not a symlink.
>
> Emacs does not create lock files that are symlinks AFAIK.

That is not true.=C2=A0 lock files are normally dangling symlinks,
i.e. their target does not exist.=C2=A0 On a few systems where lock files are not symlinks (I knew about only one: MS-Windows), lock files are
regular files, but then they are not empty.=C2=A0 And your reports indicate=
that it is a regular and empty file:

> As follows:
> $ ls -l ~/Dropbox/Documents/Projects/emacs/.#dotemacs
> -rw-r--r--@ 1 username=C2=A0 staff=C2=A0 0 May 16 07:13 /Users/usernam= e/Dropbox/Documents/Projects/emacs/.#dotemacs

This is unusual, because it means the information that a lock file
should record: the user and the process ID that locked the file -- is
not recorded anywhere.=C2=A0 It is usually recorded either in the name of the symlink's target or (if the lock file is a regular file) in the
file's contents.

So something here is not "normal".=C2=A0 If indeed on macOS lock = files are
not symlinks, they should be regular files which are not empty.=C2=A0 If you could step with a debugger through the code of the C function
create_lock_file and see what happens there when Emacs locks a file
you edit, we could make some progress in investigating this bug.

NOTICE: This email and its attachmen= ts may contain privileged and confidential information, only for the viewin= g and use of the intended recipient. If you are not the intended recipient,= you are hereby notified that any disclosure, copying, distribution, acting= upon, or use of the information contained in this email and its attachment= s is strictly prohibited and that this email and its attachments must be im= mediately returned to the sender and deleted from your system. If you recei= ved this email erroneously, please notify the sender immediately.=C2=A0 Xag= e Security, Inc. and its affiliates will never request personal information= (e.g., passwords, Social Security numbers) via email.=C2=A0 Report suspici= ous emails to security= -alerts@xage.com
--000000000000156014061897394d--