Hi,
> 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 process cwd is /var/spool/clientmqueue, and i've checked that the
> inode number for this directory doesn't change across upgrade, so we
> aren't deleting and recreating it.
Unrelated, but that the inode number didn't change in general is not a
guarantee that the directory wasn't removed and recreated, that is up to the
file system. IIRC, on UFS, the recreated directory could as well get allocated
the same inode number.
Regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
