Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030228174553.0319e828@pop3.rowe-clan.net>
Date: Fri, 28 Feb 2003 17:47:10 -0600
To: Cliff Woolley <jwoolley@virginia.edu>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: apr_lstat() fails on linux for large files
Cc: dev@apr.apache.org, dev@httpd.apache.org
In-Reply-To: <Pine.LNX.4.52.0302281510550.27515@bistromath.cs.virginia.e
 du>
References: <5.2.0.9.2.20030228134038.02fc8e30@pop3.rowe-clan.net>
 <5.2.0.9.2.20030228134038.02fc8e30@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:11 PM 2/28/2003, Cliff Woolley wrote:
>On Fri, 28 Feb 2003, William A. Rowe, Jr. wrote:
>
>> Short of turning on largefile support here and now, what about a simple
>> APR hack?  Keep an overflow flag for apr_dir_t, and when the lstat()
>> call from apr_dir_read returns EOVERFLOW, set that flag but loop and
>> grab the next legal file.
>
>Works for me.  :)

Actually, the 'right answer' is to leave the apr_fileinfo_t ->valid bits unset
if all you can recover is the name itself ;-)  All apps *should* respect those
bits if they are looking for anything other than the name.

But I still like the general idea proposed above :-)

Bill