Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 109332 - Apache can't serve files > 2GB in size
Apache can't serve files > 2GB in size
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
: 146261 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-11-06 16:40 EST by Troy Henderson
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-30 10:12:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Pseudo Solution (1 bytes, text/plain)
2003-11-07 17:23 EST, Troy Henderson
no flags Details

  None (edit)
Description Troy Henderson 2003-11-06 16:40:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030 Galeon/1.3.10

Description of problem:
When trying to serve files > 2GB in Apache, I get the following error
in /var/log/httpd/error_log

(75)Value too large for defined data type: access to <filename> failed

In fact, Apache will not even show the file in the Index of all files
in that directory.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. dd if=/dev/zero of=foo.zero bs=2k count=1101005
2. Make foo.zero available on Apache (in an Index even)

Actual Results:  foo.zero is invisible to and Index and gives the
following error when the URL is processed manually

Expected Results:  foo.zero should appear in the Index and be
available for download

Additional info:
Comment 1 Troy Henderson 2003-11-07 17:23:45 EST
Created attachment 95807 [details]
Pseudo Solution

I downloaded the newest source code for Apache and did the following

make install

and the newly installed Apache (in /usr/local/apache2) worked perfectly (had
large file support).

I then tried to modify the SPEC file for httpd-2.0.47-10.src.rpm (by adding a
line `export CPPFLAGS="-D_FILE_OFFSET_BITS=64"`) and rebuild the SRPM and then
the RPM.  After installing this RPM, apache immediately gave a Segmentation
Fault upon starting.
Comment 2 Joe Orton 2003-11-07 17:34:20 EST
It's not that simple, changing the size of off_t changes the binary
module interface, so any module packages will need to be recompiled. 
This probably isn't the right approach to solving this problem properly.
Comment 3 Troy Henderson 2003-11-07 17:44:09 EST

Do you have any suggestions as to what might be the "right" approach
to solving this problem correctly?
Comment 4 Joe Orton 2004-01-30 10:12:20 EST
To get this to work, you'd have to recompile apr, apr-util, httpd, and
every module package with -D_FILE_OFFSET_BITS=64, and would have to
patch apr to make sure that APR_OFF_T_FMT is correct.

We won't ship apr/*/httpd/* with a 64-bit off_t until this is the
upstream default, to avoid changing the binary module interface.
Comment 5 Lance Davis 2004-03-10 08:33:32 EST
I just came across this exact same issue in Red Hat Enterprise Linux 3
ES and spent a long time trying to track down what was causing it.

Not only doesnt it display the large file, it randomly halts parsing
the directory with no warning or error, ie it only displays a couple
of files and then stops.

This is a serious bug imo and needs addressing.
Comment 6 Joe Orton 2004-03-10 08:38:34 EST
Yes, it needs addressing upstream.

The fact that mod_autoindex does not handle directories containing
large file is a separate (and relatively simple to fix) bug, please
file a separate issue on that.
Comment 7 Joe Orton 2005-01-26 10:24:12 EST
*** Bug 146261 has been marked as a duplicate of this bug. ***
Comment 8 Joe Orton 2005-01-26 10:25:42 EST
FYI, this issue is fixed in the Apache httpd 2.1.x series; once a
stable httpd 2.2 release is out, this will be included in Fedora Core.

Note You need to log in before you can comment on or make changes to this bug.