Todd,

Could I suggest you check the time synchronisation between your client box (doing the linking) and the Filer? In a previous life I found that 'make' and other tools ignore files if their creation dates are in the 'future', even if it's only a few seconds to a minute.

I suspect that might explain why depending on how quickly you run the 'rm', only 2/3 or all the files vanish.

Now, all together: "Please can we have Network Time Protocol support on our filer?"

Cheers, Mike

-----Original Message----- From: Todd C. Merrill [SMTP:tmerrill@mathworks.com] Sent: Tuesday, March 16, 1999 10:43 PM To: toasters@mathworks.com Subject: filer NFS to hp700 or alpha: client cache problem?

We haven't narrowed down the problem entirely yet, but I'd thought I'd ask anyway....

During a linking stage, in linking a bunch of .o files into a library .a, the linker will grab about 2/3 of the files in a directory into the archive, and that's it. A subsequent `rm` of *.o sometimes removes only those exact 2/3 files, sometimes removes all of them, even though the archive only has 2/3 of them in it.

It seems as if the directory inode is only showing the oldest 2/3 of the files, and depending on how long it takes the `ar` and `rm` commands to execute, removes 2/3 or all of the files.

I don't suspect it's the filer; watching an `ls` of the directory from another machine (Solaris) shows all the files there. There are only about 150 .o files to archive.

Anyone aware of any client-side NFS caching problems with Alpha or HP700 boxes? The HP is running HPUX10.20 and appears to be using only NFS V2; the alpha is running Digital UNIX V4.0D and appears to be using only V3. (NFS version from `nfsstat -h hostname` on the filer.) The filer is set nfs.tcp.enable off, NetApp Release 5.2.1.

Until next time...

Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill@mathworks.com http://www.mathworks.com

---