Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> * lib/utimens.c (gl_futimens) [HAVE_UTIMENSAT]: Work around what >> appears to be a kernel bug that causes utimensat to return 280 >> instead of 0, indicating success. > > Is it known for sure that the bug will only affect the return value, and > that utimensat() will nevertheless have done its job?
That's my hypothesis. I suspect that only one code path would be so faulty. No guarantee until the bug is localized/fixed. > If not, i.e. if > you want to play safe, it would be appropriate to treat the return value > 280 like -1 / ENOSYS. That seems safe, but simulating unconditional failure is slightly risky, too, i.e., if the function actually does the job, yet the fall-through code fails. It would end up reporting a failure when there was none. I imagine that might happen due to a race that the FD-using code would be immune to, yet the file-name-using fallback code would be subject to.
