bug in x86/uclibc busybox touch

Rob Landley rob at landley.net
Sun Jan 2 13:25:06 UTC 2011


On Thursday 30 December 2010 21:50:57 Denys Vlasenko wrote:
> On Thursday 30 December 2010 03:32, Rob Landley wrote:
> > On Tue, Dec 28, 2010 at 7:45 PM, Denys Vlasenko
> >
> > <vda.linux at googlemail.com> wrote:
> > > On Thursday 16 December 2010 13:54, Natanael Copa wrote:
> > >> $ touch -t 0001010000 moo
> > >> touch: invalid date '0001010000'
> > >>
> > >> the above works with coreutils touch and interestingly enough, with
> > >> x86_64 uclibc busybox
> > >
> > > Because 1900-01-01 is a negative Unix time which doesn't fit
> > > into 32-bit long.
> >
> > A 64 bit target shouldn't have the "year 2038" problem.  Midnight
> > January 1 1970, plus or minus 68 years and change.
> >
> > > "busybox touch -t 0112130000 file" works,
> > > and sets t=-2147475600 (0x80001f70).
> > >
> > > Previous day, -t 0112130000, doesn't.
> >
> > If you ls -l the file "moo" after creating it above, its date is
> > 01-01-2000.  Not 1900.
>
> In busybox touch, it will be 19xx (on 64-bit machines,
> where date 1900-01-01 fits into time_t).

It turns out SUSv4 specifies this:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html

69-99 is prefixed with "19", 00-68 is prefixed with 20.  (That way, it never 
creates a negative epoch.)

Personally, I'd do something based on the current year, say accept 
"current-60" into the past and "current+40" into the future, since there's a 
bias for historical dates over future dates.  But if SUSv4 is going to insist 
on hardcoding in a new Y2K variant, that's its' stupid perogative.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


More information about the busybox mailing list