Attached is the updated patch. On Fri, Sep 19, 2014 at 12:33 AM, Rob Landley <r...@landley.net> wrote:
> On 09/18/14 05:38, Ashwini Sharma wrote: > > Hi Rob, > > Hi. Your last round of fixes (which I've applied a little over half of) > touched some of the files needing cleanup outside of the pending > directory. (I.E. command contributions that predated "pending".) I > updated the toys/pedning/README file listing them (so it's not just my > private list), and have been looking at a few. (Yesterday it was "touch" > and "cut" I think.) > > > Attached are the patches. This has fixes for > > > > touch: > > 1. while setting access or modify times of a file, this was causing a > > hang due to non-increment of ss. > > I actually have more fixes to touch pending: the logic is wrong for file > create. I think if you combine "touch -a -d" when creating a file, it > should set the access time to what you specified with -d but leave the > modification time at the current (creation) time? I need to read the > spec and test what the ubuntu version does. > > Query: this patch replaces the stanza I just took _out_ that tries to > work around a libc bug. Which libc is having the problem? > > Does the for loop not work? > 2 use cases here. 1. update access or modify time one at a time. __fetch()__ was checking for __TT.file__ instead of input parameter __file__. Failure here as TT.file = NULL, causes a jump to open statement in loop. Success here results in endless loop. 2. file to be touched is existing and owned by other user. In this open(O_CREAT) did succeed, but utimes() fail returning EPERM. Again the endless loop. > > 2. handling the time format for __-d__ option as per the spec > > (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html). > > The majority of this patch affects the -t case, not the -d case? > for -d case, it is taking into account the UTC time zone. > > - strcpy(toybuf, "%Y%m%d%H%M"); > date = TT.time; > - for (i=0;i<3;i++) { > - s = strptime(date, toybuf+(i&2), &tm); > - if (s) break; > - toybuf[1]='y'; > - } > + i = ((s = strchr(date, '.'))) ? s-date : strlen(date); > + if (i == 8) strcpy(toybuf, "%m%d%H%M"); > + else if (i == 10) strcpy(toybuf, "%y%m%d%H%M"); > + else if (i == 12) strcpy(toybuf, "%Y%m%d%H%M"); > + else perror_exit("bad '%s'", date); > + > if (s && *s=='.') { > - int count = sscanf(s, ".%2d%u%n", &(tm.tm_sec), &i, &len); > - > - if (count==2) tv->tv_usec = i; > - s += len; > + if ((sscanf(s+1, "%2u%n", &(tm.tm_sec), &i) != 1) || *(s+i+1)) > + error_exit("bad '%s'", date); > + s += (i+1); > > Where did the call to strptime go? This new code seems to set up toybuf > (using three separate strings instead of three cases on one string), and > then... not call strptime? I'm confused... > > my bad, attached is the updated patch. I preferred if..else over loop calling strptime() 3 times. Though the loop is kept intact now. __for__ loop works fine, but as per spec it should accept [[CC]YY]mmddMMHH[.SS], all the fields in pairs of two digits. strptime() doesn't care for this two digit format, leading '0' may or may not be there. Finally [.SS] can be in the range [00, 60] and no further fractions. sscanf(".%2d%u%n") would fail when input is like "1910200240.24" or "1910200240." (Segfault) as len is not updated properly and s is advanced by the same. (Yesterday I was looking at whether or not I could combine the date > parsing logic there with the stuff in "date". The answer is currently > "no", but I want to give it another look...) > > Have to answer the rest later, errand... > > Rob >
touch.c.patch
Description: Binary data
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net