LARGEFILE support?
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 for all the platforms' benefit. Bill
Re: [PATCH] ap_brigade_partition()
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,
you're discarding the return values from ap_bucket_read(). Those should be
returned. The prototype ought to look like:
apr_status_t ap_brigade_partition(ap_bucket_brigade *b, apr_off_t point,
ap_bucket **after_point);
Okay. It was returning a pointer because it was trying to match
ap_bucket_split() back
in the days when it was _split_offset() returning a brigade. I have no
problem with it
returning an apr_status_t now that it has a life of its own. Patch included.
Great.
...
Besides changing the return values, one thing this patch does is to ditch the
checks for
AP_BUCKET_IS_EOS, because they're kind of superfluous... if
point==brigade_len,
after_point will be the EOS bucket anyway, so as long as there's never any
data after the
EOS, this function doesn't need to check for EOS. That lets us collapse some
of the
if/elseif/else stuff and have less code duplication.
Ah. Good point.
As far as after_point goes, I've assumed in this patch that after_point need
only be set
in success cases... does that jive?
Yup.
Some comments on the patch:
*) what happens when you find a bucket with e-length == -1 ? AFAICT, the
function doesn't handle it. I'm thinking a check at the top of the loop
for a length==-1 and a read(), then do the point/length compare stuff.
*) after_point looks wrong for the manual-split case. It appears that you'd
end up with (B1a, B1b, B2) and return B2 rather than B1b.
Didn't we have another function? A copy() function or something? What
happened to that one? (or should I troll my mail archive)
Cheers,
-g
--- src/buckets/ap_buckets.c 2000/12/12 12:18:46 1.37
+++ src/buckets/ap_buckets.c 2000/12/12 17:08:56
@@ -122,48 +122,44 @@
return a;
}
-APR_DECLARE(ap_bucket *) ap_brigade_partition(ap_bucket_brigade *b,
apr_off_t point)
+APR_DECLARE(apr_status_t) ap_brigade_partition(ap_bucket_brigade *b,
+ apr_off_t point,
+ ap_bucket **after_point)
{
ap_bucket *e;
const char *s;
apr_size_t len;
+apr_status_t rv;
if (point 0)
-return NULL;
+return APR_EINVAL;
AP_BRIGADE_FOREACH(e, b) {
/* bucket is of a known length */
-if ((point e-length) (e-length != -1)) {
-if (AP_BUCKET_IS_EOS(e))
-return NULL;
-point -= e-length;
-}
-else if (point == e-length) {
-return AP_BUCKET_NEXT(e);
-}
-else {
+if (point e-length) {
/* try to split the bucket natively */
-if (ap_bucket_split(e, point) != APR_ENOTIMPL)
-return AP_BUCKET_NEXT(e);
+if ((rv = ap_bucket_split(e, point)) != APR_ENOTIMPL) {
+*after_point = AP_BUCKET_NEXT(e);
+return rv;
+}
/* if the bucket cannot be split, we must read from it,
* changing its type to one that can be split */
-if (ap_bucket_read(e, s, len, AP_BLOCK_READ) != APR_SUCCESS)
-return NULL;
+if ((rv=ap_bucket_read(e, s, len, AP_BLOCK_READ)) !=
APR_SUCCESS)
+return rv;
if (point len) {
-if (ap_bucket_split(e, point) == APR_SUCCESS)
-return AP_BUCKET_NEXT(e);
-else
-return NULL;
+*after_point = AP_BUCKET_NEXT(e);
+return ap_bucket_split(e, point);
}
-else if (point == len)
-return AP_BUCKET_NEXT(e);
-else
-point -= len;
}
+if (point == e-length) {
+*after_point = AP_BUCKET_NEXT(e);
+return APR_SUCCESS;
+}
+point -= e-length;
}
-return NULL;
+return APR_EINVAL;
}
APR_DECLARE(int) ap_brigade_to_iovec(ap_bucket_brigade *b,
--
Greg Stein, http://www.lyra.org/
Re: Build problems on BeOS R4.5
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 building APR on BeOS R4.5 (this time an i586)
again. I get the following error:
/bin/sh /boot/home/subversion/apr/libtool --mode=compile --silent gcc -DBEOS
-DBEOS -I../../include -I../../include/arch/beos -I../../include/arch/unix
-c filestat.c touch filestat.lo
/boot/home/subversion/apr/file_io/unix/filestat.c: In function
`fill_out_finfo':
/boot/home/subversion/apr/file_io/unix/filestat.c:101: structure has no
member named `st_blocks'
This error is not surprising, since as it turns out, the stat.h header
defines a struct stat without st_blocks as a member, nor with any
close analogue. The definition of stat is as follows:
struct stat {
dev_t st_dev;/* device that this file
resides on */
ino_t st_ino;/* this file's inode #, unique
per device */
mode_t st_mode; /* mode bits (rwx for user,
group, etc) */
nlink_t st_nlink; /* number of hard links to
this file */
uid_t st_uid;/* user id of the owner of
this file */
gid_t st_gid;/* group id of the owner of
this file */
off_t st_size; /* size in bytes of this file
*/
dev_t st_rdev; /* device type (not used) */
size_t st_blksize;/* preferred block size for
i/o */
time_t st_atime; /* last access time */
time_t st_mtime; /* last modification time */
time_t st_ctime; /* last change time, not
creation time */
time_t st_crtime; /* creation time */
};
I wonder if st_size/st_blksize might do the trick.
Thanks
sam th
[EMAIL PROTECTED]
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
--
Greg Stein, http://www.lyra.org/
Re: Build problems on BeOS R4.5
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 compiles on my Linux box, and fixes
that problem on the BeOS box. The Linux box also seems to test
reasonably.
Index: file_io/unix/filestat.c
===
RCS file: /home/cvspublic/apr/file_io/unix/filestat.c,v
retrieving revision 1.38
diff -u -r1.38 filestat.c
--- file_io/unix/filestat.c 2001/01/23 04:10:46 1.38
+++ file_io/unix/filestat.c 2001/01/24 09:47:54
@@ -97,10 +97,6 @@
apr_ansi_time_to_apr_time(finfo-atime, info.st_atime);
apr_ansi_time_to_apr_time(finfo-mtime, info.st_mtime);
apr_ansi_time_to_apr_time(finfo-ctime, info.st_ctime);
-if (wanted APR_FINFO_CSIZE) {
-finfo-csize = info.st_blocks * 512;
-finfo-valid |= APR_FINFO_CSIZE;
-}
if (finfo-filetype == APR_LNK) {
finfo-valid |= APR_FINFO_LINK;
}
Index: include/apr_file_info.h
===
RCS file: /home/cvspublic/apr/include/apr_file_info.h,v
retrieving revision 1.5
diff -u -r1.5 apr_file_info.h
--- include/apr_file_info.h 2001/01/23 04:10:47 1.5
+++ include/apr_file_info.h 2001/01/24 09:47:54
@@ -141,8 +141,6 @@
#define APR_FINFO_CTIME 0x0020
#define APR_FINFO_ATIME 0x0040
#define APR_FINFO_SIZE 0x0100
-#define APR_FINFO_ASIZE 0x0200
-#define APR_FINFO_CSIZE 0x0400
#define APR_FINFO_DEV0x1000
#define APR_FINFO_INODE 0x2000
#define APR_FINFO_NLINK 0x4000
@@ -190,10 +188,6 @@
apr_int16_t nlink;
/** The size of the file */
apr_off_t size;
-/** The space allocated for the file */
-apr_off_t asize;
-/** The storage size consumed by the file */
-apr_off_t csize;
/** The time the file was last accessed */
apr_time_t atime;
/** The time the file was last modified */
sam th
[EMAIL PROTECTED]
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
pgpJxMS2hR1Us.pgp
Description: PGP signature
Re: Build problems on BeOS R4.5
+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, then we can introduce them. This patch does just that. It compiles on my Linux box, and fixes that problem on the BeOS box. The Linux box also seems to test reasonably. ... patch elided ... -- Greg Stein, http://www.lyra.org/
Re: LARGEFILE support?
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 complaint, I just want to get a handle on how we proceed for all the platforms' benefit. We can't enable it by default, because that has some serious consequences on some platforms. If we want to provide a configure option, then we can turn it on whenever we want to. If we want to enable it on some platforms by default, I don't see that as a problem. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Fw: Build problems on BeOS R4.5
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 - From: Sam TH [EMAIL PROTECTED] To: dev@apr.apache.org Sent: Wednesday, January 24, 2001 3:51 AM Subject: Re: Build problems on BeOS R4.5 Doh... why didn't Outlook 'Express' borrow Outlook's resend this message options? Time to look at a Free as in beer mail client again.
Fw: cvs commit: apr-util/dbm apr_dbm.c
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 further. +1 :-) p.s. mod_rewrite could also be improved to use apr_dbm. ack.
Re: APR Changes to apr_stat and apr_getfileinfo
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
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 way. If/when
somebody really needs that feature, then we can introduce them.
I'm +.5 on retaining asize, simply becase I believe asize is inadaquately
defined. I'm strongly +1 on retaining csize, which has a very definate and
legitimate purpose for file management.
Reconsidering asize, let's drop it, and add it with an adequate definition
later.
On csize, the argument goes like this for Apache;
proxy file retention weight = csize * age
while (totalcached wantcached) {
read greatest retention weight
rm file
}
Something that is far less effective using the 'true' size.
Bill
[PATCH] what exactly does APR_FINFO_DIRENT do?
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 2001/01/24 16:16:35 1.48
+++ srclib/apr/file_io/unix/dir.c 2001/01/24 18:07:57
@@ -151,7 +151,7 @@
* only if stat will give us what this platform supports, and we can't
* get it from the platform.
* XXX: Optimize here with d_fileno, d_type etc by platform */
-wanted = ~(APR_FINFO_NAME);
+wanted = ~(APR_FINFO_NAME|APR_FINFO_DIRENT);
if (wanted)
{
char fspec[PATH_MAX];
mod_autoindex specifies APR_FINFO_DIRENT in the call to
apr_dir_read(), and it ended up getting APR_INCOMPLETE as the return
code from apr_dir_read() because apr_dir_read() didn't take out the
APR_FINFO_DIRENT bit and later thought that something wasn't handled.
I hear that mod_autoindex is broken on Win32 too. Maybe something
similar is needed?
But back to the question in the subject... I don't think
APR_FINFO_DIRENT does anything, so why do we need it?
Thanks...
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: LARGEFILE support?
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 2:42 PM Subject: Re: LARGEFILE support? 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 complaint, I just want to get a handle on how we proceed for all the platforms' benefit. We can't enable it by default, because that has some serious consequences on some platforms. If we want to provide a configure option, then we can turn it on whenever we want to. If we want to enable it on some platforms by default, I don't see that as a problem. Ryan ___ Ryan Bloom[EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -- -
Re: cvs commit: apr/file_io/unix filestat.c
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
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 | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
track socket opts patch
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
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 |= APR_FINFO_STAT should tell the user we did an lstat() instead of a stat(), and leave the APR_LNK flag to tell them that it was (or wasn't) a link. Maybe that's the bit that's fooling us all. Bill - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: William A. Rowe, Jr. [EMAIL PROTECTED] Cc: dev@apr.apache.org Sent: Wednesday, January 24, 2001 4:01 PM Subject: Re: cvs commit: apr/file_io/unix filestat.c 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 | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr-util/include apr_hooks.h
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 10:52:57PM -, [EMAIL PROTECTED] wrote: ben 01/01/24 14:52:57 Modified:server config.c hooksapr_hooks.c include apr_hooks.h Log: The current hooking module is _not_ a debugging aid. Revision ChangesPath 1.106 +1 -1 httpd-2.0/server/config.c Index: config.c === RCS file: /home/cvs/httpd-2.0/server/config.c,v retrieving revision 1.105 retrieving revision 1.106 diff -u -r1.105 -r1.106 --- config.c2001/01/23 04:14:24 1.105 +++ config.c2001/01/24 22:52:52 1.106 @@ -347,7 +347,7 @@ printf(Registering hooks for %s\n,m-name); apr_debug_module_hooks=1; } - apr_debug_module_name=m-name; + apr_current_hooking_module=m-name; m-register_hooks(p); } } 1.31 +2 -2 apr-util/hooks/apr_hooks.c Index: apr_hooks.c === RCS file: /home/cvs/apr-util/hooks/apr_hooks.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- apr_hooks.c 2001/01/24 22:05:32 1.30 +++ apr_hooks.c 2001/01/24 22:52:54 1.31 @@ -73,7 +73,7 @@ APU_DECLARE_DATA apr_pool_t *apr_global_hook_pool = NULL; APU_DECLARE_DATA int apr_debug_module_hooks = 0; -APU_DECLARE_DATA const char *apr_debug_module_name = NULL; +APU_DECLARE_DATA const char *apr_current_hooking_module = NULL; /* NB: This must echo the LINK_##name structure */ typedef struct @@ -322,7 +322,7 @@ pHook-aszPredecessors=aszPre; pHook-aszSuccessors=aszSucc; pHook-nOrder=nOrder; -pHook-szName=apr_debug_module_name; +pHook-szName=apr_current_hooking_module; if(apr_debug_module_hooks) apr_show_hook(szName,aszPre,aszSucc); } 1.35 +3 -3 apr-util/include/apr_hooks.h Index: apr_hooks.h === RCS file: /home/cvs/apr-util/include/apr_hooks.h,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- apr_hooks.h 2001/01/19 07:01:26 1.34 +++ apr_hooks.h 2001/01/24 22:52:56 1.35 @@ -103,7 +103,7 @@ pHook-aszPredecessors=aszPre; \ pHook-aszSuccessors=aszSucc; \ pHook-nOrder=nOrder; \ -pHook-szName=apr_debug_module_name; \ +pHook-szName=apr_current_hooking_module; \ if(apr_debug_module_hooks) \ apr_show_hook(#name,aszPre,aszSucc); \ } @@ -232,9 +232,9 @@ /** * The name of the module that is currently registering a function - * @defvar apr_pool_t *apr_debug_module_name + * @defvar apr_pool_t *apr_current_hooking_module */ -extern APU_DECLARE_DATA const char *apr_debug_module_name; +extern APU_DECLARE_DATA const char *apr_current_hooking_module; /** * Register a hook function to be sorted -- Greg Stein, http://www.lyra.org/
