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.
I think that you can force a touch on the files in question, but I'm not sure. Linux machines don't have a problem with it nor do AIX machines. The cutoff date is later than the Big Band era, the Unix time universe starts at 0000Z01Jan70 or for the Civilian world 1200 AM GMT Jan, 1, 1970 (remember this is before UTC was invented in the 90s so it was still called Greenwich Mean Time) <scw>
On Wed, Jun 21, 2006 at 05:08:06PM +0100, David Lee wrote:
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, Stephen C Woods wrote:
I think that you can force a touch on the files in question, but I'mnot sure. Linux machines don't have a problem with it nor do AIX machines. The cutoff date is later than the Big Band era, the Unix time universe starts at 0000Z01Jan70 or for the Civilian world 1200 AM GMT Jan, 1, 1970 (remember this is before UTC was invented in the 90s so it was still called Greenwich Mean Time)
<scw>
Drifting off topic! My recollection of something I'd seen somewhere about this technical problem was that, if the dates could actually be presented, they would be somewhere in the 1940s thus predating the well-known UNIX baseline of "1 Jan 1970". (Hence my aside about "Big Band era".)
This would be because of poorly handled sign-wrapping on various timestamp fields, especially triggered when PC clients are writing files.
In other emails on this thread, a couple of people suggested a workaround for Solaris 8. I've just tried that... it worked... lo and behold it does indeed display dates of 1948.
-
Anthony Salazar -
David Lee -
Stephen C Woods