Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Oct 2025 11:19:54 +0200
From:      Olivier Certner <olce@freebsd.org>
To:        Lexi Winter <ivy@freebsd.org>
Cc:        fs@freebsd.org, current@freebsd.org
Subject:   Re: openat("./...", O_CREAT) fails even though the directory exists
Message-ID:  <2507674.THHZn3L5Ee@ravel>
In-Reply-To: <aOy5LUUu5DCwY_XZ@amaryllis.le-fay.org>
References:  <aOy5LUUu5DCwY_XZ@amaryllis.le-fay.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4139707.kAAoriTUSa
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Olivier Certner <olce@freebsd.org>
To: Lexi Winter <ivy@freebsd.org>
Cc: fs@freebsd.org, current@freebsd.org
Date: Mon, 13 Oct 2025 11:19:54 +0200
Message-ID: <2507674.THHZn3L5Ee@ravel>
In-Reply-To: <aOy5LUUu5DCwY_XZ@amaryllis.le-fay.org>
References: <aOy5LUUu5DCwY_XZ@amaryllis.le-fay.org>
MIME-Version: 1.0

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
--nextPart4139707.kAAoriTUSa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmjsxDsACgkQjKEwQJce
JicB2g/+O0t55zTnIEFesmimRGVQf+iUa8ZeH601m3me8yznZGPPb9K2FsxeqdE4
P/N1eKunPTQUHp9d8NvyGj0L2JA6mUB84D7JoL/ZGe6PVeh7iplnaEVgbseEk690
xG56C19jU7/TiEwv+cuPdpIpU4QXvUogiFSgOULZBXeTmJmmnTCvF/Fy1GdEeH11
ksDb6rPKa2/8glLVMM9DSF5VK0UFFMzBYEkRX7A+ewbWGX/RM52b2goUkKkyxWIL
sqdrtU4Dr/zXjMRHTCnp1xc0ILPqKrjr7hnHVQZz/A1Fm/hr0CTmlz/BmpzfDjec
nQHrTa7tOQ+3A8+Q0DEXTNghOlMXq6YupepgE0+BBsem0Ve6kbfWaghTXJW3eKdS
KJ6fM1vSjrzeuIsGMdBzrvfQOHfJp2r0Ah1egNH5MtdN2qAmiL14UqpwMj6Vb9jW
diDCGLRq2TidPG0HYRQwbcmcvgKs93N/d5xkEf4VB6duc/Gcw20Vac8015M0d92b
iDLIG8PmEJnMe3TqkREjGpet3icLuxNoReibsS2GPC05UX5og72PtEaduEetF5qX
2HLg43MhYzlXKYGNpmhcd0mXG9rxctyGLsS7MdUwGrp3QkjVZRy3YCHxNhiCNZwA
j5Q0U1l51AzHg56irrmgC3ye1oXqNer3nd1/qQGD1CGHlFjxgbU=
=9SOv
-----END PGP SIGNATURE-----

--nextPart4139707.kAAoriTUSa--






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2507674.THHZn3L5Ee>