Hi all, ok, that was a simple one, but I was looking on the wrong numbers: All answers pointed the same way: The date of these files has been far in the future and so time_t was overflowing [msc]time I corrected these (touch won't do this, so I used Blastwave-rsync to copy them and then moved them to the old name) and all was right again. Now I only have to watch for the NFS-Client with a wrong configured date ... Thanks Mats, Tony and Andy for your fast responses! Greetings Jan Dreyer Jan Dreyer schrieb: > Hi, > running Solaris 10u3 I'm running into the following problem: > -- snipp -- > >/usr/bin/ls -l > ./20070921_14310: Value too large for defined data type > ./20070921_14309: Value too large for defined data type > ./20070921_14125: Value too large for defined data type > [...] > >/usr/bin/sparcv9/ls -l > total 6716 > [...] > -rw-rw-r-- 1 user05 104 363828 Nov 29 2076 20070921_14125 > -rw-rw-r-- 1 user05 104 6928 Nov 29 2076 20070921_14309 > -rw-rw-r-- 1 user05 104 234089 Nov 29 2076 20070921_14310 > [...] > -- snapp -- > > So far not a problem (though I do wonder, why a 32-bit application can't > show these files). But I can't find a 64-bit version of find, which is > used by nfsfind; nfsfind starts by cron weekly and bugs me with "Value > too large" messages ... > > Any suggestions? > > Greetings > Jan Dreyer _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Oct 4 06:25:16 2007
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:07 EST