GNU bug report logs - #8572
du/bigtime skip reason

Previous Next

Full log

Message #14 received at 8572 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8572 <at> debbugs.gnu.org
Subject: Re: bug#8572: du/bigtime skip reason
Date: Thu, 28 Apr 2011 11:49:58 +0200

Hi Paul,

> > $ ./coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
> > 0
> > 
> > $ ./coreutils-8.12-32bit/src/touch -d @922337203685477580 future; echo $?
> > ./coreutils-8.12-32bit/src/touch: invalid date format `@922337203685477580'
> > 1

And the 'date' program's interpretation of the same date:

$ coreutils-8.12-64bit/src/date -d @922337203685477580
coreutils-8.12-64bit/src/date: time 922337203685477580 is out of range

$ coreutils-8.12-32bit/src/date -d @922337203685477580
coreutils-8.12-32bit/src/date: invalid date `@922337203685477580'

> Is it the message "invalid date format" that's the problem?
> So you're suggesting that the message be improved to say "date out of range", or
> something like that?  That would make sense; I'm just trying to make
> sure that's what you're asking for.

I'm asking for two things:
1) In tests/du/bigtime, to distinguish errors that are due to the 'time_t' type
   from errors that are due to the file system. When I get the error message
   "file system cannot represent big time stamps" I am led to believe that
   it's a problem with the 'ext3' file system, and actually it is not: the
   reason is some behavioural difference between 32-bit and 64-bit of the
   'touch' program.
2) To have a consistent interpretation of @922337203685477580 as an input date
   between 'touch' and 'date' and between 32-bit and 64-bit binaries on the
   same machine.

Bruno
-- 
In memoriam Heinz Droßel <http://en.wikipedia.org/wiki/Heinz_Drossel>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.