I've seen this many times myself as a former Unix Sysadmin working in a mixed Solaris, Linux, Windows and Mac environment. Solaris can't see any dates previous to the epoch (1972?) Linux (at least RedHat) can see timestamps back to the year 1900 so NFS mounting to a linux workstation was how I managed to fix date-timestamps.
Michael Cope NetApp Professional Services Engineer
mcope@NetApp.com Cell: (858) 204-2400 txt msg: 8582042400@vtext.com
Simplifying Data Storage Management
-----Original Message----- From: David Lee [mailto:t.d.lee@durham.ac.uk] Sent: Wednesday, June 21, 2006 9:08 AM To: toasters@mathworks.com Subject: Value too large for defined data type
We administer our filers from a Solaris 8 machine: this is where the home directories (on the NetApp) for new users are created, and from where they are removed for old users.
Occasionally removal of the home directory and its contents partially fails: Value too large for defined data type
An "ls -lR" on the residual directory gives similar "Value too large ..." message for the residual files that the "rm ..." has been unable to remove.
I cannot find a definitive statement about this, but I recall (and strongly suspect) something to do with a timestamp (ctime, mtime, atime etc.) having some sort of integer sign-bit wrap-around issue (and that if _were_ able to display it, the result would typically have a year in the big-band 1940s era...) And that NFS (from our Solaris 8 admin machine) has trouble with such things.
Is this likely to be the problem? If so, are there any recommended solutions (or paths to investigate)? Thanks.