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.