[PATCH libapreq-1.2] Re: [PATCH mp1.28] Clean up file uploaded by test suite

[Steve Hay <st...@uk.radan.com>]

Stas Bekman wrote:

> Steve Hay wrote:
>
>> Stas Bekman wrote:
>>
>>> Do we have the same problem with Apache::Request?
>>
>>
>>
>> I don't think so, but I'm not sure where the uploaded data gets 
>> spooled to by Apache::Request.  (CGI.pm created "CGItemp<number>" 
>> files in my C:\Temp directory.  Where does Apache::Request put this 
>> data?)
>
>
> You can specify the temp dir in new(), with TEMP_DIR. it uses the 
> apreq prefix for temp files. see ApacheRequest_tmpfile() in 
> standard/c/apache_request.c. 

Thanks.  We definitely don't have a problem in that regard then: 
ApacheRequest_tmpfile() calls ap_register_cleanup(..., remove_tmpfile, 
...), and remove_tmpfile() very sensibly calls ap_pfclose() before remove().

In fact, I hadn't spotted it yesterday, but Apache::Upload has a 
tempname() method that tells me exactly where the file went!  It is 
indeed cleaned up OK.

That's the good news.

The bad news is that the TEMP_DIR setting that you've just drawn my 
attention to doesn't work as documented, at least on Windows.

In my case, the default temporary directory used was C:\WINDOWS\Temp, 
but when I tried changing it to C:\Temp via that TEMP_DIR setting, I 
found that it made no difference - the uploaded file still got spooled 
into C:\WINDOWS\Temp.

A look at the MS documentation for their implementation of the standard 
C library routine tempnam(), which ApacheRequest_tmpfile() uses, says of 
the first argument, "Target directory to be used if TMP not defined".  
The "TMP" there is a reference to the TMP environment variable.

I had the Apache service running as the LocalSystem account, for which 
TMP is evidently defined as C:\WINDOWS\Temp by the system.  Sure enough, 
if I reconfigure Apache to run as the user "steveh", whose TMP 
environment variable is defined as "C:\DOCUME~1\steveh\LOCALS~1\Temp" 
(again by the system), then the uploaded file now gets spooled into 
there, again ignoring my TEMP_DIR setting.

How does tempnam() behave on other OS's?  My K&R makes no mention of 
environment variables coming into play.

If it's only Windows that behaves this way then I'm happy to provide a 
DOC PATCH to describe this behaviour.

Alternatively, the attached patch fixes it for me.  It works by simply 
clearing the TMP environment variable for the duration of the tempnam() 
call.  Note that it only does that if TEMP_DIR has been set, otherwise 
tempnam() has no directory specified to work with, which makes it 
default to the value of P_tmpdir in <stdio.h>, which is "\\" -- not very 
nice!

- Steve

[DOC PATCH] Re: [PATCH libapreq-1.2] Re: [PATCH mp1.28] Clean up file uploaded by test suite

[Steve Hay <st...@uk.radan.com>]

Joe Schaefer wrote:

>Steve Hay <st...@uk.radan.com> writes:
>  
>
>>How does tempnam() behave on other OS's?  My K&R makes no mention of
>>environment variables coming into play.
>>    
>>
>
>glibc's documented behavior for tempnam() is similar to MS's 
>(except they use "TMPDIR" instead of "TMP"):
>
>  % man 3 tempnam
>    ...
>    Attempts to find an  appropriate  directory  go through the
>    following steps: (i) In case the environment variable TMPDIR exists
>    and  contains  the  name  of  an appropriate  directory, that is used.  
>    ...
>
>  
>
>>If it's only Windows that behaves this way then I'm happy to provide a DOC
>>PATCH to describe this behaviour.
>>    
>>
>
>+1.
>
OK, then here's patch for Request.pm's POD.

It also cleans up a couple of whitespace-only lines which podchecker 
doesn't like, and removes the =over 4 ... =back commands that the 
=head2's were enclosed in because podchecker didn't like them either.

- Steve

Re: [PATCH libapreq-1.2] Re: [PATCH mp1.28] Clean up file uploaded by test suite

[Joe Schaefer <jo...@sunstarsys.com>]

Steve Hay <st...@uk.radan.com> writes:


[...]

> In my case, the default temporary directory used was C:\WINDOWS\Temp,
> but when I tried changing it to C:\Temp via that TEMP_DIR setting, I
> found that it made no difference - the uploaded file still got spooled
> into C:\WINDOWS\Temp. A look at the MS documentation for their
> implementation of the standard C library routine tempnam(), which
> ApacheRequest_tmpfile() uses, says of the first argument, "Target
> directory to be used if TMP not defined".  The "TMP" there is a
> reference to the TMP environment variable.

FWIW, here's what POSIX (v3) says about tempnam():

  char *tempnam(const char *dir, const char *pfx);

  DESCRIPTION

  The tempnam() function shall generate a pathname that may be used for
  a temporary file. 

  The tempnam() function allows the user to control the choice of a
  directory. The dir argument points to the name of the directory in which
  the file is to be created. If dir is a null pointer or points to a
  string which is not a name for an appropriate directory, the path prefix
  defined as P_tmpdir in the <stdio.h> header shall be used. If that
  directory is not accessible, an implementation-defined directory may be
  used.

It conveniently omits any mention of what should happen if dir
*is* a valid directory name.

> How does tempnam() behave on other OS's?  My K&R makes no mention of
> environment variables coming into play.

glibc's documented behavior for tempnam() is similar to MS's 
(except they use "TMPDIR" instead of "TMP"):

  % man 3 tempnam
    ...
    Attempts to find an  appropriate  directory  go through the
    following steps: (i) In case the environment variable TMPDIR exists
    and  contains  the  name  of  an appropriate  directory, that is used.  
    ...

> If it's only Windows that behaves this way then I'm happy to provide a DOC
> PATCH to describe this behaviour.

+1.

-- 
Joe Schaefer