We are finding an increasing number of user files (several thousand files at present) with bizarre dates, eg
-rwx--x--x 1 rfx3 ug93 49 Dec 27 1931 /usr/fsa/ug93/rfx3/letter-home -rwx--x--x 1 socx12 socs 460 Jul 22 1948 /usr/fsa/extn/socx12/nov2nd
The dates display mainly in the 1930s although there are a few around the year 2009! These files seem to have been created over CIFS from PCs running Windows 95.
It becomes a real problem if you run Solaris 7 which seems to have numerous bugs in the area of NFS file dates. It won't read, write or delete these files - it says "Value too large for user buffer". It's all related to 64-bit vs 32-bit Solaris and whether dates are signed or unsigned. SGI systems and older Solaris systems don't have the problem.
Having talked to Sun I tried patching the kernel variable nfs_32_time_ok to be 0xffffffff which appears to fix it, except it breaks other things like the utime system call.
The best option at present seem to be to run a weekly script on a non-solaris 7 system to find the bad files and "touch" them.
Any ideas anyone?
------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk ------------------------------------------------------
Regardless of whether or not the dates are being set due to a bug or improper setup with the clients or even with the filer, Solaris should not be choking. The correct solution is to get Sun to issue a real working patch, and not to use Solaris 7 in the meantime.
Bruce
Hi !
We've seen strange dates also from older Solaris, after copying between filers with ndmpcopy... Strange enough... no explanation...
Anyway, have someone seen "Block Limit Reached" messages in user's logins ? It is one of our strangest still-open problems....
Eyal/Motorola.
Bruce Sterling Woodcock wrote:
Regardless of whether or not the dates are being set due to a bug or improper setup with the clients or even with the filer, Solaris should not be choking. The correct solution is to get Sun to issue a real working patch, and not to use Solaris 7 in the meantime.
Bruce
On Thu, 25 Nov 1999, Bruce Sterling Woodcock wrote:
Regardless of whether or not the dates are being set due to a bug or improper setup with the clients or even with the filer, Solaris should not be choking. The correct solution is to get Sun to issue a real working patch, and not to use Solaris 7 in the meantime.
The problem is not limited to Solaris 7. I encountered the same problem on one of my Solaris 2.5.1 boxes. I was trying to remove an entire directory and it simply refused to remove one particular file. Since it was just one file I just pushed the whole issue aside until I could get back to it later. The next day I tried the remove again and this time it worked but then I realized I was not logged in on the Solaris machine this time but instead I was using on of our older Sunos 4.1.4 machines.
-
Bruce Sterling Woodcock -
Dave Atkin -
David H. Brierley -
Eyal Traitel