[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8572: du/bigtime skip reason
From: |
Bruno Haible |
Subject: |
bug#8572: du/bigtime skip reason |
Date: |
Thu, 28 Apr 2011 13:40:17 +0200 |
User-agent: |
KMail/1.9.9 |
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>