httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wichitill <>
Subject Re: [apreq-2] $upload->tempname on Win32
Date Mon, 05 Jul 2004 11:29:23 GMT
>> From the discussion so far, I'll once again point out that
>> everyone seems to be able to open $upload->tempname using
>> either "<" or "<:APR".  The associated issues need to be
>> documented (I'm certainly _not_ volunteering for that),
>> and if there's a way to make the decision programatically,
>> let's please include that in our fh() implementation so our
>> users don't have to worry about making the right choice.

> I'm not sure what would be gained either (I assume this is
> all a Win32 issue). Markus, are you suggesting that the
> APR_DELONCLOSE flag used in the apr_file_mktemp() call
> within apreq_file_mktemp() of src/apreq.c be dropped, and
> that the temp files subsequently left around be cleaned up
> explicitly by apreq? That would allow Perl's open() to be
> used, instead of the current demand of APR::PerlIO, in this
> context, but would there be a strong reason for doing this?
> APR::PerlIO is already available, and Joe's recent fh()
> implementation within Apache::Upload already returns a
> filehandle using APR::PerlIO behind the scenes.

The practical problem on Win32 is that I can't pass $upload->tempname to
someone else's code (maybe an external program that can't accept handles)
since that code won't use APR::PerlIO and therefore won't be able to make
any use of the exclusively locked tempfile. I haven't tested $upload->link
yet, but I'd assume a created NTFS hardlink will be similarly useless during
the request, if the linking works at all.

I don't know enough of the internals to actually suggest anything. I'm just
wondering if relying on the OS to delete the file doesn't make things more
complicated than necessary, and who knows what other problems could come up
with other filesystems (NFS? SMB shares? What do I know).

View raw message