Received: (qmail 23423 invoked by uid 2012); 12 Oct 1999 23:55:49 -0000 Message-Id: <19991012235549.23422.qmail@hyperreal.org> Date: 12 Oct 1999 23:55:49 -0000 From: Joseph Drozdik Reply-To: joseph@etunnels.com To: apbugs@hyperreal.org Subject: stat in http_request.c ->get_path_info returns EOVERFLOW then self-corrects eventually after hitting web-client reload button. X-Send-Pr-Version: 3.2 >Number: 5136 >Category: os-solaris >Synopsis: stat in http_request.c ->get_path_info returns EOVERFLOW then self-corrects eventually after hitting web-client reload button. >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: feedback >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Tue Oct 12 20:10:22 PDT 1999 >Closed-Date: >Last-Modified: Wed Jun 07 12:40:33 PDT 2000 >Originator: joseph@etunnels.com >Release: 1.3.9 >Organization: >Environment: SunOS sea-svr-01 5.7 Generic_106541-02 sun4u sparc Two solaris boxes conneced nfs with automount. gcc 2.8.1 >Description: I'm trying to create a set of webpages that allows directory index viewing from a webserver to a remote filesystem over nfs. I go to a sample url and the dir listing tipically comes up fine. Sometimes the icon for a folder or the parent dir arrow will be replaced with unknown.gif. If I browse to a subdir then come back 99% of the time I will get a permission denied page with these errors logged. [Thu Oct 7 19:55:36 1999] [error] [client 209.17.141.34] (79)Value too large for defined data type: access to /htdocs/c/ failed 209.17.141.34 - - [07/Oct/1999:19:55:36 -0700] "GET /htdocs/c/ HTTP/1.1" 403 298 What happened is that in the file http_request.c in the function get_path_info the stat call returned EOVERVLOW. If I try a url that is still on the webserver there are no errors and no icon corruptions. This and the fact that the remote access works sometimes leads me to believe that I don't have any config problems. I wrote small program to test stating over nfs with apache permissions to see if I was having networking problems. I couldn't generate any errors. Any ideas? It would be nice for the sake of scalability if Apache could work reliably in this kind of environment. >How-To-Repeat: In your document tree put a soft symlink to an nfs mounted directory. Put some subdirs in the target directory. Access the remote dirs with a browser and browse up and down the remote tree. If you see a broken parent dir icon try its link anb browse up. >Fix: >Release-Note: >Audit-Trail: State-Changed-From-To: open-feedback State-Changed-By: marc State-Changed-When: Tue Oct 12 20:44:04 PDT 1999 State-Changed-Why: This really doesn't sound like it has much to do with Apache. Are you sure you have the latest patch clusters on your Solaris boxes? If not, maybe you should. If so, maybe you shouldn't. As the Solaris stat() man page says: EOVERFLOW The file size in bytes or the number of blocks allocated to the file or the file serial number cannot be represented correctly in the structure pointed to by buf. If a stat() on a directory returns that, then.. well... not much Apache can do to cause that. There are any number of reasons your test program may not show it. It may have to do with the way it is compiled or linked or with having to do certain things in a particular sequence with particular times between them. Comment-Added-By: coar Comment-Added-When: Wed Jun 7 12:39:45 PDT 2000 Comment-Added: [This is a standard response.] This Apache problem report has not been updated recently. Please reply to this message if you have any additional information about this issue, or if you have answers to any questions that have been posed to you. If there are no outstanding questions, please consider this a request to try to reproduce the problem with the latest software release, if one has been made since last contact. If we don't hear from you, this report will be closed. If you have information to add, BE SURE to reply to this message and include the apbugs@Apache.Org address so it will be attached to the problem report! >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]