>The NFS RFC's (1813 for NFSv3) define atime/mtime/ctime as unsigned 32
>bit numbers. Solaris 7's NFS enforces this more strictly than previous
>versions and won't play nicely with files who have negative timestamps.
>Whether this is a feature or a bug depends on who you ask.
Practically speaking, it means that Solaris 7 won't interoperate with
anyone else. We've had several problems with our Solaris 7 clients and
Netapp file servers due to files with timestamps before 1970. I can't
tell users, with a straight face, that this is because Netapp is broken;
after all, Netapp works with all our _other_ clients.
The worst consequence of this problem is that if you want to have
reliable file utilities in Solaris 7, you _must_ compile them in 64-bit
mode and run the 64-bit OS. Large-file mode won't cut it, and the
32-bit OS won't cut it either. E.g., suppose I do the following on a
Solaris 2.5.1 client with a Netapp server:
sol251$ export TZ=UTC0
sol251$ touch -t 191811111100 armistice
sol251$ ls -l armistice
-rw-rw-r-- 1 eggert eggert 0 Nov 11 1918 armistice
Then suppose I try to use `find', or `ls' or any shell script based on
standard utilities on Solaris 7. They'll*up royally:
sol7$ ls -l armistice
armistice: Value too large for defined data type
I have to build GNU ls in 64-bit mode, and run it in a 64-bit OS,
for `ls' to not*up royally:
sol7$ gnuls -l armistice
-rw-rw-r-- 1 eggert eggert 0 Dec 17 2054 armistice
The time stamp may not be interpreted compatibly with Solaris 2.5.1,
due to Solaris 2.5.1 converting it to nfstime3 incorrectly,
but that's OK: at least I can ls the file!
Here's what Sun should do, if it wants to do things right:
1. Ship 64-bit safe file utilities so that my shell scripts keep working.
This is just as important as making the utilties large-file safe.
I shouldn't have to worry that `dd' or `find' will bug out on me;
they should work on all files.
2. The 32-bit OS should not reject negative NFS timestamps, since there's
no way for the poor user to recover in that case -- there's no
64-bit mode to escape to. In other words, the 32-bit OS should
continue to be compatible with Solaris 2.6 in this matter.