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.
