On Mon, 12 Mar 2007, Vinay Y S wrote:
On 3/12/07, Joe Schaefer <[EMAIL PROTECTED]> wrote:
[ ... ]
Here's a different suggestion to try:
[ ... ]
In other words, delete the file *before* closing it.
This shouldn't matter. My version is apreq2-2.0.8 with Apache
2.2.2/2.2.4 build with Visual Studio 2003 running on Windows XP SP2
with all updates.
I'm not sure if this is relevant, but the problems we
found earlier with this is with VC++ 6, which must be
used for compatibility with ActivePerl.
I don't know the perl code, but I would assume it would be doing all
it's stuff(open/copy/closing the temp file) before either of the two
cleanup functions are called above.
So, if we apply the patch suggested by Joe or me(second patch) and fix
the perl code which originally triggered all this discussion, all
should be fine.
You're probably right about fixing the perl code; however,
this may lie somewhere in the Perl/mod_perl side of things.
And due to the nature of the failures, it's a hard thing
to track down.
Just in case it wasn't clear from the earlier messages, the
failures we found were only in the upload test of the perl
glue; running it many (>15) times in rapid succession
resulted in occasional (and seemingly, randomly occuring)
stray temp files remaining. The problem seemed worse on
Steve's system compared to mine, although we were running
similar software versions (Windows XP, VC++ 6, httpd-2.2.2,
and the latest perl-5.8 and mod_perl at the time). The
"fix" that was introduced seemed to help this problem,
which I agree doesn't make sense from the C side. However,
as one of the major consumers of libapreq2 in the Win32
world are people running ActivePerl with similar setups
who install this via ppm, it's important to support that
side of things.
It may be that this was a problem outside of libapreq2;
since the time of the above failures, I've upgraded perl,
mod_perl, and Apache, and haven't encountered similar
failures with either your patch or Joe's. I would though
like to get Steve's experiences with this, as his setup
encountered more of the original failures.
--
best regards,
Randy
