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.
A co-worker encountered this same problem today and I've been looking into it. We're going to try the nfs:nfs_allow_preepoch_time=1 workaround in /etc/system. See Solution ID ntapcs1470 on NOW.
On Wed, Jun 21, 2006 at 10:53:34AM -0700, Cope, Michael wrote:
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.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
On Wed, 21 Jun 2006, Adam McDougall wrote:
A co-worker encountered this same problem today and I've been looking into it. We're going to try the nfs:nfs_allow_preepoch_time=1 workaround in /etc/system. See Solution ID ntapcs1470 on NOW.
Many thanks. That has fixed it. It now displays dates, and they are way back in 1948!
By the way, just to clarify for the archives: the required line in "/etc/system" for Solaris 8 starts with "set", thus: set nfs:nfs_allow_preepoch_time=1
On Wed, Jun 21, 2006 at 10:53:34AM -0700, Cope, Michael wrote:
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.
For Sol7 there is the tunable nfs:nfs_32_time_ok. For Sol8 there is the tunable nfs:nfs_allow_preepoch_time.
Greetings,
On Wed, 21 Jun 2006, Michael van Elst wrote:
On Wed, Jun 21, 2006 at 10:53:34AM -0700, Cope, Michael wrote:
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.
For Sol7 there is the tunable nfs:nfs_32_time_ok. For Sol8 there is the tunable nfs:nfs_allow_preepoch_time.
Thanks. I can confirm the Solaris 8 variant: set nfs:nfs_allow_preepoch_time=1
now displays dates successfully, way back in 1948!
-
Adam McDougall -
Cope, Michael -
David Lee -
Michael van Elst