[Toybox] [Patch] - touch, kill and umount fixes

[Ashwini Sharma]

Attached is the updated patch.

On Fri, Sep 19, 2014 at 12:33 AM, Rob Landley <rob at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20140919/ed305dbd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: touch.c.patch
Type: application/octet-stream
Size: 1569 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20140919/ed305dbd/attachment-0002.obj>