perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: updating r->finfo on $r->filename($newfile)
Date Mon, 27 Oct 2003 21:41:28 GMT

> +1, but won't be better for Apache provide an API to set r->filename 
> which will take care of updating finfo?

yes, but you saw how quickly the thread died out when that idea was 

> If Apache doesn't provide this 
> API, and wants users to do that when they really want to (as it involves 
> an overhead), perhaps we shouldn't do that as we did in mp1 but instead 
> document that one has to update $r->finfo, if they need to and leave 
> things 1:1 with C API.

except there's no $r->finfo API, right?

which brings me to my next question.  IIRC, when we last talked about 
$r->finfo you said it wasn't likely to happen since there is no apr_status_t 
mapping for perl's stat() (or something like that :)

is it really impossible, or just a really complex typemap?  I, for one, miss 
$r->finfo activity, and would like to see _something_ in mp2.  maybe an API 
that's different from 1.0:

use Apache::Finfo ();

my $finfo = $r->finfo;
$finfo->update(stat $foo);
$mtime = (stat _)[9];

$finfo->size(-s $bar);


> Another idea would be to provide a variation of filename() which will 
> set filename and update finfo. e.g. filename_finfo()?

maybe.  I think either the apache API (which will never come) or our own 
access to $r->finfo is a better approach.

> So it looks like you are safe, since all we want is the mod time.

cool, thanks :)

> If you intend to keep these traces, they shouldn't be _o, which is used 
> for I/O tracing.

I kinda thought is was IO, since the new logic involves (underlying) stat 
calls.  but ok - whatever you think is best is fine with me.

> please don't hardcode 'htdocs', see other tests that work with files, 
> using Apache::Test->config->vars->{documentroot}

> It's probably better to use the approach used in t/hooks/cleanup2.t, so 
> you sleep the minimal amount of time using a more finegrained select and 
> checking for the timestamp with -M will ensure that it'll certainly be 
> different (in case some OS has a bad sleep granularity).

ok, I'll change those.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message