On Fri, Jan 28, 2022 at 7:37 AM Scott Cheloha <[email protected]> wrote:
> On Fri, Jan 28, 2022 at 07:28:40AM -0700, Todd C. Miller wrote: > > On Thu, 27 Jan 2022 20:02:18 -0800, Philip Guenther wrote: > > > > > > I think futimens(2) and close(2) failures are exotic enough to > warrant > > > > printing the system call name. > > > > > > I don't understand this. Can you give an example of an error message > that > > > touch currently might emit where knowing that the failed call was > > > futimens() or close() would affect the analysis of how to deal with > it? I > > > mean, it looks like the only errors that futimens() could really > return are > > > EROFS, EIO, and EPERM (implies a race by different users to create the > > > file), and close() could only return EIO. For any of those errors, > you're > > > going to handle them the same whether they're from open, futimens, or > > > close, no? > > > > I agree. The actual syscall in this case is pretty much irrelevant. > > The mostly likely failure is due to an I/O error of some kind. > > Alright, you have both convinced me. > > We'll go with this patch? > Sure (but I think the rval assignment and warn() call should be in a consistent order). Philip Guenther
