GNU bug report logs - #72641
31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

Previous Next

Full log

Message #19 received at 72641 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michal Nazarewicz <mina86 <at> mina86.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 72641 <at> debbugs.gnu.org
Subject: Re: bug#72641: 31.0.50; "Unlocking file: Invalid argument" when
 deleting lock file on network file system
Date: Thu, 15 Aug 2024 20:20:36 -0700

[Message part 1 (text/plain, inline)]

On 2024-08-15 17:59, Michal Nazarewicz wrote:

> However, if I save the file (be it by save-buffer or by killing the
> buffer and picking save option), the lock file remains....
> - unlock_file is called
>    - it calls current_lock_owner
>      - which return ENOENT for some reason
>    - the lock file is left alone

Obviously current_lock_owner should not return ENOENT if there is an 
existing lock file - that would defeat the purpose of having a lock 
file. We need to get to the bottom of why current_lock_owner returns ENOENT.

From inspection, current_lock_owner returns ENOENT only if Emacs 
notices that the "lock" file is actually an empty regular file (or looks 
stale), and calls 'unlink' on it, and 'unlink' fails with errno == 
ENOENT. Is that what's actually happening? You can use a debugger or 
'strace' to confirm.

Come to think of it, if 'unlink' fails with errno == ENOENT, that means 
there's no lock file so current_lock_owner should return 0. This is true 
because of NFS and similar network file systems where unlink can fail 
even though it actually removed the file. I installed the attached patch 
to fix this; a similar problem exists elsewhere, so this patch fixes all 
the instances of it in Emacs master.

With this patch, current_lock_owner should never return ENOENT and we 
can move on to the next problem you observe, if there is one.


> In desperation I’ve tried attached patch (it adds `if (!lfinfolen)
> return I_OWN_IT`; big diff is because than `if (lfinfolen)` check can be
> removed and code dedented) and it worked.

Yes, that doesn't sound right; on non-buggy file systems the invalid 
lock file would cause races to occur, if I'm reading the code correctly.

Let's see what happens with current master before proceeding in any 
direction like that.

[0001-Port-better-to-NFS-unlink.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.