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

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