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
--- apache_request.c.orig 2003-04-30 15:53:10.000000000 +0100
+++ apache_request.c 2003-08-21 10:24:22.000000000 +0100
@@ -475,11 +475,23 @@
{
request_rec *r = req->r;
FILE *fp;
+#ifdef WIN32
+ char *tmpval = NULL;
+ char settmp[MAX_PATH + 4];
+#endif
char prefix[] = "apreq";
char *name = NULL;
int fd = 0;
int tries = 100;
+ /* tempnam() ignores our temp_dir on Win32 if TMP is set */
+#ifdef WIN32
+ if (req->temp_dir != NULL) {
+ tmpval = getenv("TMP");
+ putenv("TMP=");
+ }
+#endif
+
while (--tries > 0) {
if ( (name = tempnam(req->temp_dir, prefix)) == NULL )
continue;
@@ -490,6 +502,13 @@
free(name);
}
+#ifdef WIN32
+ if (tmpval != NULL) {
+ sprintf(settmp, "TMP=%s", tmpval);
+ putenv(settmp);
+ }
+#endif
+
if ( tries == 0 || (fp = ap_pfdopen(r->pool, fd, "w+" "b") ) == NULL ) {
ap_log_rerror(REQ_ERROR, "[libapreq] could not create/open temp file");
if ( fd >= 0 ) { remove(name); free(name); }--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
