+-- On Monday, December 04, 2000 14:54:05 -0800 mitch@netline.com wrote: | We just ran across a strange happening on our F760 filer. One of our | folks did a "du -s" on an RCS directory to see how much space it was | using: | | => du -s RCS | du: RCS/ParseNVP.pm,v: Value too large for defined data type | | And got a strange error. In fact, pretty much anything that would | do a stat(2) call on this file in this directory would generate | the same error message. There were no errors logged on the filer | and all weekly messages seem to indicate that all is well, but it | still puzzles me. | | I ran off for the requisite caffine boost and came back and am now | unable to reproduce the problem. I asked the user if they perhaps | did something such as recreating the RCS directory from another | source... they hadn't. | | The file which was complained about is a mere 3422 bytes, and all | timestamps indicate that the file has not changed recently. | | Has anybody else seen this problem or have any ideas on how/why this | may have occurred? | | For what it's worth, the NFS client accessing the files is running | Solaris 5.7. I unfortunately didn't pop over to one of my BSD boxes | before the problem worked itself out. +--
NFS defines all dates to be 32 bit unsigned values but many clients, including older Solaris clients ignore this and treat it as a 32 bit signed value. Starting with Solaris 7 Sun began enforcing the standard and refuse to accept a date after 2038 as the standard requires. Presumably filers use a 32 bit date and hence can accept it and still follow the standard.
/Michael