LARGEFILE support?

2001-01-24 Thread William A. Rowe, Jr.
Question, if we enable largefile support for unix, the apr_finfo_t-size, apr_off_t, and so forth all become 64 bit identities? Are we prepared to do so today? Consequences? Win32 absolutely handles 64 bit file sizes/offsets without complaint, I just want to get a handle on how we proceed

Re: [PATCH] ap_brigade_partition()

2001-01-24 Thread Greg Stein
Now that we're actually using this function, I figured it was time to dig in and spend the time with this patch. :-) On Tue, Dec 12, 2000 at 09:11:07AM -0800, Cliff Woolley wrote: --- Greg Stein [EMAIL PROTECTED] wrote: This patch is much better, and I've gone ahead and applied it. However,

Re: Build problems on BeOS R4.5

2001-01-24 Thread Greg Stein
We should simply nuke the asize and csize since they are nearly impossible to deal with in any reasonable cross-platform way. If/when somebody really needs that feature, then we can introduce them. Cheers, -g On Wed, Jan 24, 2001 at 03:01:12AM -0600, Sam TH wrote: Well, I recently tried

Re: Build problems on BeOS R4.5

2001-01-24 Thread Sam TH
On Wed, Jan 24, 2001 at 01:27:43AM -0800, Greg Stein wrote: We should simply nuke the asize and csize since they are nearly impossible to deal with in any reasonable cross-platform way. If/when somebody really needs that feature, then we can introduce them. This patch does just that. It

Re: Build problems on BeOS R4.5

2001-01-24 Thread Greg Stein
+1 On Wed, Jan 24, 2001 at 03:51:20AM -0600, Sam TH wrote: On Wed, Jan 24, 2001 at 01:27:43AM -0800, Greg Stein wrote: We should simply nuke the asize and csize since they are nearly impossible to deal with in any reasonable cross-platform way. If/when somebody really needs that feature,

Re: LARGEFILE support?

2001-01-24 Thread rbb
On Wed, 24 Jan 2001, William A. Rowe, Jr. wrote: Question, if we enable largefile support for unix, the apr_finfo_t-size, apr_off_t, and so forth all become 64 bit identities? Are we prepared to do so today? Consequences? Win32 absolutely handles 64 bit file sizes/offsets without

Fw: Build problems on BeOS R4.5

2001-01-24 Thread William A. Rowe, Jr.
From: William A. Rowe, Jr. [EMAIL PROTECTED] To: Sam TH [EMAIL PROTECTED] Sent: Wednesday, January 24, 2001 9:09 AM Subject: Re: Build problems on BeOS R4.5 -1 on the patch to apr_fileinfo_t, +1 on the patch to file_io/unix/filestat.c in the short run. Bill - Original Message -

Fw: cvs commit: apr-util/dbm apr_dbm.c

2001-01-24 Thread William A. Rowe, Jr.
From: Greg Stein [EMAIL PROTECTED] Sent: Wednesday, January 24, 2001 7:44 AM Note that we're almost at the point where mod_auth_db.c can be tossed, in favor of always using mod_auth_dbm (against apr_dbm). Once NDBM is inserted into apr_dbm, then mod_auth_dbm can be simplified a bit

Re: APR Changes to apr_stat and apr_getfileinfo

2001-01-24 Thread Ben Collins-Sussman
Greg Stein [EMAIL PROTECTED] writes: apr_item_t shouldn't have been used, so it seems right to change keysort.c to use an SVN structure. Yeah, so I created an svn_item_t (in svn_types.h) instead.

Re: Build problems on BeOS R4.5

2001-01-24 Thread William A. Rowe, Jr.
From: William A. Rowe, Jr. [EMAIL PROTECTED] Sent: Wednesday, January 24, 2001 9:08 AM From: Greg Stein [EMAIL PROTECTED] Sent: Wednesday, January 24, 2001 3:27 AM We should simply nuke the asize and csize since they are nearly impossible to deal with in any reasonable cross-platform

[PATCH] what exactly does APR_FINFO_DIRENT do?

2001-01-24 Thread Jeff Trawick
This patch gets mod_autoindex working again for me: Index: srclib/apr/file_io/unix/dir.c === RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v retrieving revision 1.48 diff -u -r1.48 dir.c --- srclib/apr/file_io/unix/dir.c

Re: LARGEFILE support?

2001-01-24 Thread David Reid
This seems like the correct way to go. Of course autoconf checks for platforms that use it tos witch on the support can also be added. david - Original Message - From: [EMAIL PROTECTED] To: William A. Rowe, Jr. [EMAIL PROTECTED] Cc: dev@apr.apache.org Sent: Wednesday, January 24, 2001

Re: cvs commit: apr/file_io/unix filestat.c

2001-01-24 Thread William A. Rowe, Jr.
trawick 01/01/24 13:11:52 Modified:file_io/unix filestat.c Log: get filestat.c to compile again and it rides again, I presume? Thanks Jeff

Re: cvs commit: apr/file_io/unix filestat.c

2001-01-24 Thread Jeff Trawick
William A. Rowe, Jr. [EMAIL PROTECTED] writes: trawick 01/01/24 13:11:52 Modified:file_io/unix filestat.c Log: get filestat.c to compile again and it rides again, I presume? Thanks Jeff autoindex is still failing for me; I'll play with it some more -- Jeff Trawick

track socket opts patch

2001-01-24 Thread David Reid
Folks, I know we said we'd until after beta 1, but any objections if I commit the patch over the next day or so? Seems like it's a reasonable optimisation that might as well be in the tree for people. david

Re: cvs commit: apr/file_io/unix filestat.c

2001-01-24 Thread William A. Rowe, Jr.
That's odd - it works flawlessly for me. The bug's gotta be in apr_stat, since I mod_autoindex looks at nothing but the filename and creates the subrequest to parse each file entry. Hmmm... could be the apr_lstat variety, better be sure we clear that flag out. I'm thinking that -valid |=

Re: cvs commit: apr-util/include apr_hooks.h

2001-01-24 Thread Greg Stein
Man... it would just be nice to get rid of the damned globals. apr_global_hook_pool and apr_current_hooking_module. It would mean a couple extra parameters to the ap_hook_whatever() functions, but the control/data flow would be a bit more obvious that way. Cheers, -g On Wed, Jan 24, 2001 at