Re: openat("./...", O_CREAT) fails even though the directory exists

From: Lexi Winter <ivy_at_freebsd.org>
Date: Mon, 13 Oct 2025 09:27:20 UTC
Olivier Certner wrote in <2507674.THHZn3L5Ee@ravel>:
> > 44288: fstatat(AT_FDCWD,"./df59D8I2px044288",0xecbda905210,0x0) ERR#2 'No such file or directory'
> > 44288: fstatat(AT_FDCWD,".",{ mode=drwxr-xr-x ,inode=129826,size=2,blksize=131072 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
> > 44288: geteuid()                                 = 0 (0x0)
> > 44288: fstatat(AT_FDCWD,".",{ mode=drwxr-xr-x ,inode=129826,size=2,blksize=131072 },0x0) = 0 (0x0)
> > 44288: openat(AT_FDCWD,"./df59D8I2px044288",O_RDWR|O_CREAT|O_EXCL,0600) ERR#2 'No such file or directory'
> > 
> > this doesn't make sense to me: since "." exists, how can openat() return
> > ENOENT here?
> 
> How do you come to this conclusion?  In what you pasted above, and in
> the full traces, the openat(AT_FDCWD) fails on the same file
> ("./df59D8I2px044288") on which the fstatat(AT_FDCWD) just above
> already failed with ENOENT.  So the most plausible explanation is that
> that file just does not exist at this point.

the file should not exist, and this is expected.  the truss output shows:

- "./df59D8I2px044288" does not exist: fstatat() returns ENOENT.  this
  is expected, because this is a new file we are trying to create (if it
  existed, this would be a different error).

- "." exists: fstatat(AT_FDCWD, ".") returns 0

- trying to create "./df59D8I2px044288", which doesn't exist, with
  O_CREAT|O_EXCL fails with ENOENT.

the issue is in the last item: since this file doesn't exist, and we're
opening it with O_CREAT, how can this fail?

after some more debugging, i think what's going on here is that pkg(8)
is deleting and recreating /var/spool/mqueue on upgrade, which means
smmsp's open fd to that directory is no longer valid, and therefore
openat() returns this unusual error.

i am not sure how to fix this, but the impact is that upgrading the
FreeBSD-sendmail package breaks sendmail on a running system, so we
need to fix this somehow for 15.0.  i suspect the fix will be in pkgbase
somewhere: for example, we could restart sendmail on upgrade, or tell
the user to do that.