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>
