[19425] in Athena Bugs
Re: sun4 9.0.12: find
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Thu Jul 26 03:08:18 2001
Message-Id: <200107260708.DAA10802@brad-majors.mit.edu>
To: Greg Hudson <ghudson@MIT.EDU>
cc: "Thomas L. Thornton" <tomt@MIT.EDU>, bugs@MIT.EDU
In-Reply-To: Your message of "Wed, 25 Jul 2001 15:32:08 EDT."
<200107251932.PAA07472@egyptian-gods.MIT.EDU>
Date: Thu, 26 Jul 2001 03:08:15 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> find has changed, since we upgraded from Solaris 7 to Solaris 8. I
>> checked in Sunsolve for a similar bug report or a relevant patch, but
>> wasn't able to find either. So, it may be a problem on our end.
>> I'll let you know if we find out anything more.
I looked into this; it's not a problem with find as such; the problem
is that the file "scripts" in /mit/tomt/Pismire/ has ctime/mtime/atime
from before 1970:
File: "scripts"
Size: 1276 Blocks: 4 Regular File
Access: (0644/-rw-r--r--) Uid: (27786/ UNKNOWN) Gid: ( 101/ xfs)
Device: 7 Inode: 1889539430 Links: 1
Access: Wed Dec 31 18:59:59 1969
Modify: Wed Dec 31 18:59:59 1969
Change: Wed Dec 31 18:59:59 1969
This is making any 32 application running on a machine with the 64 bit
kernel that stat()'s the file get EOVERFLOW. It's trivial to reproduce:
[zacheiss/root@brad-majors] ~$ touch -t 196901010059.42 HOW_TO_PAGE_ME
[zacheiss/root@brad-majors] ~$ more HOW_TO_PAGE_ME
HOW_TO_PAGE_ME: Value too large for defined data type
but only occurs for files on remote filesystems (NFS and AFS tested); it
works correctly on local disk:
[zacheiss/root@brad-majors] /var/tmp$ cp ~/HOW_TO_PAGE_ME .
[zacheiss/root@brad-majors] /var/tmp$ touch -t 196901010059.42 HOW_TO_PAGE_ME
[zacheiss/root@brad-majors] /var/tmp$ ls -l HOW_TO_PAGE_ME
-rw------- 1 zacheiss mit 976 Jan 1 1969 HOW_TO_PAGE_ME
64 bit applications work, and just return a wonky time:
[zacheiss/root@brad-majors] /usr/bin$ /usr/bin/sparcv9/ls -l /mit/tomt/Pismire/scripts
-rw-r--r-- 1 27786 mit 1276 Feb 7 2106 /mit/tomt/Pismire/scripts
Cruising around sunsolve indicates the problem has been known ever since
the 64 bit kernel was introduced.
Garry