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 14:36:37 -0700 Message-ID: References: <867cfujge6.fsf@gnu.org> <86fruhiwt0.fsf@gnu.org> <868r09ivqn.fsf@gnu.org> <867cftiprt.fsf@gnu.org> <86msoph6wt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000053416806189908ba" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18476"; 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 23:39:19 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 1s7iop-0004Vh-FN for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 May 2024 23:39:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s7ioY-0006BK-LX; Thu, 16 May 2024 17:39: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 1s7ioW-0006Ae-N2 for bug-gnu-emacs@gnu.org; Thu, 16 May 2024 17:39: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 1s7ioW-0002JB-C5 for bug-gnu-emacs@gnu.org; Thu, 16 May 2024 17:39:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s7ioY-0004dx-Bw for bug-gnu-emacs@gnu.org; Thu, 16 May 2024 17:39: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 21:39: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.171589548317819 (code B ref 70973); Thu, 16 May 2024 21:39:02 +0000 Original-Received: (at 70973) by debbugs.gnu.org; 16 May 2024 21:38:03 +0000 Original-Received: from localhost ([127.0.0.1]:51145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7inb-0004dL-5z for submit@debbugs.gnu.org; Thu, 16 May 2024 17:38:03 -0400 Original-Received: from mail-lj1-f180.google.com ([209.85.208.180]:56752) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7inY-0004cq-F8 for 70973@debbugs.gnu.org; Thu, 16 May 2024 17:38:01 -0400 Original-Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2df848f9325so15328581fa.1 for <70973@debbugs.gnu.org>; Thu, 16 May 2024 14:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715895411; x=1716500211; 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=83e8fCh+acjISgYuxLTphVPz5VpTufxDpH+3ydhhjiQ=; b=ZRuVi6ZpfxCXZTqExu0+ilJLGtSzGXqaUgk59JNabsZ81bLCtNhT/YmpITe2Xpp7oU fmXz1KzNNBdPh5TaYxXLCXgPxRDd49ZUaiJ/XXx6s9gISRg2tSEAqJ3nBO1H7Pr9RUGn O1p3snElhzHkRMAFW/LUu1aNL/bGBz/XkUVD6vulEpHf1o8Oe7bHH/N6pMR7gA5KGuOl ZefDwkpsbblGTYrRKy5gJo+CLDY65fgLFc8X0YvYoSJ+T0z287/fr5gHtLp5uEqPQZZE 6sGAnzoEiubaOVPP3m4ybCjie2Okx2zQDoklqKQtcNiyKHSEu+dvUEl7N591VgXF47gJ cVjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715895411; x=1716500211; 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=83e8fCh+acjISgYuxLTphVPz5VpTufxDpH+3ydhhjiQ=; b=iaoKn1fKlZF5dOQFYzWfVnJH16gEkGL1T+kpLoK05JZurSEdUtvdR2Hv40KpsT6j4h ZoP7U9hhvFJPFo5MzfuIM8Nuho4km9liylzvZjX19lewd8vco26fqKB/SaB+t0vpy7sz Yjua+3NPTgV17OhnyKdZI4lFPxioJvaMqSa0U/zw7jkDc3S6eYnshZnv34L0tbtrrl7q jmsqdQ/J9XjT9n7Gd+P6lKnCrRiPYOSAoEFVmwEaGufzX1YBvjFxRxXjbX+k8frE5KYd +wReZeOR3MdmdDKs7FcbnsA1TmWOTReIlo1RopdZTCayxs0OT5eR4vxbSbf+DwpsM9hZ I0dA== X-Gm-Message-State: AOJu0Yx/S2BWs8SgGbwQ25WkbpoXbA2n1KvJRFBNCgzMxt7Z00bArMyR iFuRZ4oRYCJegwUYtJ6bE2arRsIiCf01defiThW9vPqizaSLAvBg5gZ4LabMV/8= X-Google-Smtp-Source: AGHT+IFSSz6v9xHdhZIG11BQ8KPRQO9a/DWfg9OlybJTu5I4wHLURehVwJlR78twbYodRyZEMbX7AA== X-Received: by 2002:a05:651c:78e:b0:2e0:a39b:2b25 with SMTP id 38308e7fff4ca-2e5204b2d6bmr114341731fa.48.1715895410902; Thu, 16 May 2024 14:36:50 -0700 (PDT) Original-Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com. [209.85.208.50]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-574eaace761sm3892385a12.91.2024.05.16.14.36.49 for <70973@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 May 2024 14:36:49 -0700 (PDT) Original-Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-572d2461001so4154068a12.0 for <70973@debbugs.gnu.org>; Thu, 16 May 2024 14:36:49 -0700 (PDT) X-Received: by 2002:a50:9f21:0:b0:572:6249:96bc with SMTP id 4fb4d7f45d1cf-5734d67eea4mr14607869a12.32.1715895408990; Thu, 16 May 2024 14:36:48 -0700 (PDT) In-Reply-To: <86msoph6wt.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:285207 Archived-At: --00000000000053416806189908ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would agree that the issue was likely due to a system crash at an inopportune moment. Of course, if emacs did detect a bad lock file, it could prompt the user for confirmation before removing / replacing it. No need to be silent. The status quo, requiring a user to find and remove the lock file manually, seems burdensome to my eye, albeit the issue is presumably rare. But certainly it is a matter of taste. On Thu, May 16, 2024 at 12:52=E2=80=AFPM Eli Zaretskii wrote= : > > From: Duncan Greatwood > > Date: Thu, 16 May 2024 12:27:05 -0700 > > Cc: 70973@debbugs.gnu.org > > > > 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 actuall= y > 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 th= e > 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_fil= e > 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 th= e > case where they are not symlinks > > and/or are of zero size, avoiding the need to remove the > partially-written lock file manually. > > I'm not sure we should silently sweep these rare and special cases > under the carpet. The warning is just a warning, and manually > deleting the lock file fixes even that. > > So I'm not sure we should do anything here, as long as the conclusion > is that this happened due to a system crash in an opportune moment. > --=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 --00000000000053416806189908ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would agree that the issue was likely due to a system cr= ash at an inopportune moment.

Of course, if emacs did de= tect a bad lock file, it could prompt the user for confirmation before remo= ving / replacing it. No need to be silent.

The sta= tus quo, requiring a user to find and remove the=C2=A0lock file manually, s= eems burdensome to my eye, albeit the issue is presumably rare. But certain= ly it is a matter of taste.



On Thu, May = 16, 2024 at 12:52=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Duncan Greatwood <dgreatwood@gmail.com>
> Date: Thu, 16 May 2024 12:27:05 -0700
> Cc: 70973@d= ebbugs.gnu.org
>
> I just tried editing a different file, client.cc, causing a lockfile t= o be created. Sure enough, just as you say, that
> lockfile is a dangling symlink:
> ls -al .#client.cc
> lrwxr-xr-x@ 1 username=C2=A0 staff=C2=A0 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 actual= ly 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=A0 staff=C2=A0 40 May 16 11:43 .#dotemacs -&= gt; username@DMG-MB-Air-15-2024.local.3071
>
> At this point, I tried doing a hard reboot (power cycle) to simulate t= he kernel crash I mentioned before. But
> (not surprisingly) after the reboot the lock file still looks as you w= ould expect.
> ls -l .#dotemacs
> lrwxr-xr-x@ 1 username=C2=A0 staff=C2=A0 40 May 16 11:43 .#dotemacs -&= gt; username@DMG-MB-Air-15-2024.local.3071
>
> Noting that, in the bad case, the lock file was not only not a danglin= g symlink as it should be, but was also of
> zero size, I would speculate that the kernel crash happened right as e= macs was part way through writing the
> lockfile to disk.
>
> Taking a quick look at the emacs source, the C function create_lock_fi= le 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 su= spect that
> the kernel crash terminated the symlink write before it could fully co= mplete.
>
> To fix, perhaps emacs needs to check purported lock files and handle t= he case where they are not symlinks
> and/or are of zero size, avoiding the need to remove the partially-wri= tten lock file manually.

I'm not sure we should silently sweep these rare and special cases
under the carpet.=C2=A0 The warning is just a warning, and manually
deleting the lock file fixes even that.

So I'm not sure we should do anything here, as long as the conclusion is that this happened due to a system crash in an opportune moment.

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
--00000000000053416806189908ba--