On Mon, May 05, 2025 at 08:43:18AM -0700, Junio C Hamano wrote: > But for other kind of requirements, we want to fulfill them on all > platforms that we claim to support. Using open_nofollow() to > achieve hard atomicity requirement would be a bug in such a > situation. Should we somehow warn our developers against its use? The comment above the declaration says: /* * Open with O_NOFOLLOW, or equivalent. Note that the fallback equivalent * may be racy. Do not use this as protection against an attacker who can * simultaneously create paths. */ int open_nofollow(const char *path, int flags); though that may not be enough. 00611d8440 (add open_nofollow() helper, 2021-02-16) discusses a way that it could be made less racy, at a slightly increased cost. IMHO that is somewhat orthogonal to the issue here, though, which is purely about the case where O_NOFOLLOW does exist (ironically, our racy fallback code consistently returns ELOOP ;) ). The issue at hand is that particular errno responses are not always portable. The patch discussed here improves that. My point was more that I'm not sure to what degree we should care about errno consistency in our wrappers (which is inherently a bit whack-a-mole as we find new cases), versus trying not to care too hard about specific errno values in calling code. I can see arguments either way (and as I said, an argument for making errno values consistent even if we try to rely on them less). Mostly I was just a little surprised to see open_nofollow() being used in this way (especially since we have to end up stat()-ing anyway to check for other cases). -Peff
