bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file

[Paul Eggert]

On 2/11/21 11:43 PM, Eli Zaretskii wrote:
> > From: Matt Armstrong <matt@rfc20.org>

> > In this case, Paul's commit changes the current_lock_owner() function
> > such that it returns zero upon ENOTDIR. The caller must interpret the
> > zero return as meaning "at the time current_lock_owner() was called,
> > nobody owned the lock file...or the lock file was obsolete."
> >
> > ENOTDIR has a specific meaning that we can rely on. Both ENOENT and
> > ENOTDIR imply that the file was definitely not on disk at the time of
> > the call. Because of this, current_lock_owner() can safely conclude that
> > nobody owned the lock.
>
> "Definitely"? "safely"?  How do you arrive at that conclusion?
>
> The Posix spec of 'unlink' says:

Matt was talking about current_lock_owner, a function that does not call 
'unlink', so it's not clear why the 'unlink' spec is relevant here.

current_lock_owner eventually calls either readlinkat or (on systems 
without symlinks) openat. If either fails with ENOTDIR, some ancestor of 
the lock file is a non-directory, hence the lock file itself cannot 
possibly exist and therefore it must be the case that nobody owns the 
lock. This is true regardless of which particular ancestor is a 
non-directory. (The lockfile name does not end in "/", so we needn't 
worry about that case here.)