GNU bug report logs -
#8572
du/bigtime skip reason
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 14 years and 114 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.