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

Previous Next

To reply to this bug, email your comments to 8572 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Bruno Haible <bruno <at> clisp.org>
To: bug-coreutils <at> gnu.org
Subject: du/bigtime skip reason
Date: Thu, 28 Apr 2011 01:21:00 +0200

Hi,

building coreutils 8.12 on a Linux 2.6.25.20, glibc 2.8 machine, "make check"
shows these lines in 32-bits only (not in 64-bit builds):

  bigtime: skipped test: file system cannot represent big time stamps
  SKIP: du/bigtime

The message suggests that it's a problem with the file system. But then,
why do I get the SKIP then in a 32-bit build and a PASS in a 64-bit build?

The answer is that the behaviour of the 'touch' program depends on whether
it is built in 32-bit mode or in 64-bit mode:

$ ./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

I would argue that when entering a date, this should not happen. For numbers,
ok, but here a number is meant to be converted to a date.

Bruno
-- 
In memoriam Marian Batko <http://pl.wikipedia.org/wiki/Marian_Batko>
<http://en.auschwitz.org.pl/m/index.php?Itemid=8&id=478&option=com_content&task=view>

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8572 <at> debbugs.gnu.org
Subject: Re: bug#8572: du/bigtime skip reason
Date: Wed, 27 Apr 2011 19:54:12 -0700

On 04/27/11 16:21, Bruno Haible wrote:
> $ ./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
> 
> I would argue that when entering a date, this should not happen.

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.

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

From: Jim Meyering <jim <at> meyering.net>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8572 <at> debbugs.gnu.org
Subject: Re: bug#8572: du/bigtime skip reason
Date: Thu, 28 Apr 2011 11:29:30 +0200

Bruno Haible wrote:
> building coreutils 8.12 on a Linux 2.6.25.20, glibc 2.8 machine, "make check"
> shows these lines in 32-bits only (not in 64-bit builds):
>
>   bigtime: skipped test: file system cannot represent big time stamps
>   SKIP: du/bigtime
>
> The message suggests that it's a problem with the file system. But then,
> why do I get the SKIP then in a 32-bit build and a PASS in a 64-bit build?
>
> The answer is that the behaviour of the 'touch' program depends on whether
> it is built in 32-bit mode or in 64-bit mode:
>
> $ ./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
>
> I would argue that when entering a date, this should not happen. For numbers,
> ok, but here a number is meant to be converted to a date.

Hi Bruno,
That use of touch has to depend on the file system since it sets
stat.st_mtime and stat.st_atime.  On systems with 32-bit st_*time
fields, touch has to diagnose failures like the above when the
supplied value is too wide for a 32-bit slot.

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>

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

From: Bruno Haible <bruno <at> clisp.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 8572 <at> debbugs.gnu.org
Subject: Re: bug#8572: du/bigtime skip reason
Date: Thu, 28 Apr 2011 13:40:17 +0200

Hi Jim,

> That use of touch has to depend on the file system since it sets
> stat.st_mtime and stat.st_atime.

But why is (in 64bit mode) 'touch' accepting a date that 'date' rejects?

$ coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
0
$ coreutils-8.12-64bit/src/date -d @922337203685477580
coreutils-8.12-64bit/src/date: time 922337203685477580 is out of range

If printing a date is harder than assigning that date to a file, how is then
"ls -l" doing it?

$ coreutils-8.12-64bit/src/ls -l f*
-rw-r--r-- 1 bruno users  48 31. Mär 01:57 foo1.c
-rw-r--r-- 1 bruno users 244 31. Mär 01:57 foo.c
-rw-r--r-- 1 bruno users   0 922337203685477580 future

Hmm. A single column instead of 3 columns? Wouldn't it be better to print

-rw-r--r-- 1 bruno users   0 10. Sep 29227704432 future

Then programs which expect 3 columns for the date will continue to work.

> On systems with 32-bit st_*time 
> fields, touch has to diagnose failures like the above when the
> supplied value is too wide for a 32-bit slot.

So, this means 32-bit programs cannot reliably read the date of a file?
Oh indeed:

$ coreutils-8.12-64bit/src/ls -l future 
-rw-r--r-- 1 bruno users 0 922337203685477580 future
$ coreutils-8.12-32bit/src/ls -l future 
-rw-r--r-- 1 bruno users 0 13. Okt 1942  future

So, the error message "file system cannot represent big time stamps" was wrong;
instead: "the touch program's time_t type cannot represent big time stamps"
would have been correct.

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

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

From: Jim Meyering <jim <at> meyering.net>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8572 <at> debbugs.gnu.org
Subject: Re: bug#8572: du/bigtime skip reason
Date: Thu, 28 Apr 2011 13:58:55 +0200

Bruno Haible wrote:
> Hi Jim,
>
>> That use of touch has to depend on the file system since it sets
>> stat.st_mtime and stat.st_atime.
>
> But why is (in 64bit mode) 'touch' accepting a date that 'date' rejects?
>
> $ coreutils-8.12-64bit/src/touch -d @922337203685477580 future; echo $?
> 0
> $ coreutils-8.12-64bit/src/date -d @922337203685477580
> coreutils-8.12-64bit/src/date: time 922337203685477580 is out of range
>
> If printing a date is harder than assigning that date to a file, how is then
> "ls -l" doing it?
>
> $ coreutils-8.12-64bit/src/ls -l f*
> -rw-r--r-- 1 bruno users  48 31. Mär 01:57 foo1.c
> -rw-r--r-- 1 bruno users 244 31. Mär 01:57 foo.c
> -rw-r--r-- 1 bruno users   0 922337203685477580 future
>
> Hmm. A single column instead of 3 columns? Wouldn't it be better to print
>
> -rw-r--r-- 1 bruno users   0 10. Sep 29227704432 future
>
> Then programs which expect 3 columns for the date will continue to work.
>
>> On systems with 32-bit st_*time
>> fields, touch has to diagnose failures like the above when the
>> supplied value is too wide for a 32-bit slot.
>
> So, this means 32-bit programs cannot reliably read the date of a file?
> Oh indeed:
>
> $ coreutils-8.12-64bit/src/ls -l future
> -rw-r--r-- 1 bruno users 0 922337203685477580 future
> $ coreutils-8.12-32bit/src/ls -l future
> -rw-r--r-- 1 bruno users 0 13. Okt 1942  future
>
> So, the error message "file system cannot represent big time stamps" was wrong;
> instead: "the touch program's time_t type cannot represent big time stamps"
> would have been correct.

Right.  Though actually it's the type of timespec.tv_sec (time_t)
that matters, and that is selected by you when you choose to build
32- or 64-bit binaries.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8572 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#8572: du/bigtime skip reason
Date: Thu, 28 Apr 2011 14:41:03 +0200

Bruno Haible <bruno <at> clisp.org> writes:

> If printing a date is harder than assigning that date to a file, how is then
> "ls -l" doing it?
>
> $ coreutils-8.12-64bit/src/ls -l f*
> -rw-r--r-- 1 bruno users  48 31. Mär 01:57 foo1.c
> -rw-r--r-- 1 bruno users 244 31. Mär 01:57 foo.c
> -rw-r--r-- 1 bruno users   0 922337203685477580 future
>
> Hmm. A single column instead of 3 columns? Wouldn't it be better to print
>
> -rw-r--r-- 1 bruno users   0 10. Sep 29227704432 future

29227704432 is not representable in int tm_year, thus localtime fails.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Previous Next

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