Me and CC-ed Mati had it some time ago... HP/UX just read it with no problems at all.

It seems some bug with Solaris I think... We never insetigad it more than just deleting the files from the HP/UX machine...

Eyal.

---------------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! ---------------------------------------------------------------------- Eyal Traitel - Filer Escalation Engineer CNA, MCSE, CSA, NACA

Network Appliance BV Holland Office Center Kruisweg 799b 2132 NG, Hoofddorp The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Email: eyal@netapp.com ---------------------------------------------------------------------- Get answers NOW! - NetApp On the Web - http://now.netapp.com ----------------------------------------------------------------------

-----Original Message----- From: Chris Lamb [mailto:skeezics@measurecast.com] Sent: Tuesday, December 05, 2000 4:46 AM To: mitch@netline.com Cc: toasters@mathworks.com Subject: Re: Strange problem...

[...]

du: RCS/ParseNVP.pm,v: Value too large for defined data type

[snip]

Has anybody else seen this problem or have any ideas on how/why this may have occurred?

Yup. I called this in as a bug report about four or five months ago. I could probably dig up the case #, but I think it's closed...

This filer that first displayed this problem is running both CIFS and NFS, and I thought (at first) that it might be a bug related to using a "mixed" security style. But the problem appeared even on volumes that were not - nor had they ever been - anything but Unix-style security, nor even accessed once by a CIFS client. The odd thing is, when those files would pop up I could go in and delete them via CIFS...

For what it's worth, the NFS client accessing the files is running Solaris 5.7. I unfortunately didn't pop over to one of my BSD boxes before the problem worked itself out.

I first encountered this using RCS on Solaris 7 as well (both SPARC & x86). I figured it might be some obscure bug related to file locking and the NFS lock manager, but then someone reported that a _core file_ was displaying the same oddball symptoms...

The workaround (if you have CIFS licensed) is to try deleting the file via CIFS. If that doesn't work, try again via NFS - you may find that just as mysteriously as it appeared, the error will then go away and you'll be able to delete (or access) the file. Tickling it via CIFS seems to get it "unstuck." Very odd. And, I know, not very scientific. ;-) I suppose I should have shut down the box and wack'ed it upside its WAFL, just to see if there really is some insidious directory corruption waiting to bite me on the backside at some inopportune time. But I don't really have the luxury of an extended downtime, and since it appears there's a crude workaround, I haven't (to my deep shame :-) re-opened the case and pestered for a fix...

-- Chris

-- Chris Lamb, Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com