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?
Index: touch.c
===================================================================
RCS file: /cvs/src/usr.bin/touch/touch.c,v
retrieving revision 1.26
diff -u -p -r1.26 touch.c
--- touch.c 10 Mar 2019 15:11:52 -0000 1.26
+++ touch.c 28 Jan 2022 15:35:07 -0000
@@ -137,9 +137,18 @@ main(int argc, char *argv[])
/* Create the file. */
fd = open(*argv, O_WRONLY | O_CREAT, DEFFILEMODE);
- if (fd == -1 || futimens(fd, ts) || close(fd)) {
+ if (fd == -1) {
rval = 1;
warn("%s", *argv);
+ continue;
+ }
+ if (futimens(fd, ts) == -1) {
+ warn("%s", *argv);
+ rval = 1;
+ }
+ if (close(fd) == -1) {
+ warn("%s", *argv);
+ rval = 1;
}
}
return rval;
