bug#8572: du/bigtime skip reason

[Bruno Haible]

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>