Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of vinay.ys@gmail.com designates
 209.85.134.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JylqUyprtnl6c1g4e6PiwZrmoh+Op+e60BUkl6Irlw5oEICqWcQwEtGbo7PSyyIvlbkrBQWaVkCX7vv6JrXRC95Uw/aTpVIjw3rUnzeSGIYwk5GJ9jSIIzzeWJAEZyQo+tVISa65VHjKgXSklSLCdUv0kHTpplvtj1LRKvus6TA=
Message-ID: <86047d060703120020v6c6094bclddd13c53d98efb53@mail.gmail.com>
Date: Mon, 12 Mar 2007 12:50:52 +0530
From: "Vinay Y S" <vinay.ys@gmail.com>
To: apreq-dev@httpd.apache.org
Subject: Re: apreqXXXXXX temp files remain after processing uploads greater
 than 256kb. Further large upload fails
In-Reply-To: <877itnz3ei.fsf@gemini.sunstarsys.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <86047d060703081005g6ab5dd7ay36a7483adf2b0b89@mail.gmail.com>
	 <87zm6m2y5s.fsf@gemini.sunstarsys.com>
	 <Pine.LNX.4.64.0703101315410.4409@theoryx5.uwinnipeg.ca>
	 <86047d060703102312v45048b1by6b1c9805dda60c7f@mail.gmail.com>
	 <Pine.LNX.4.64.0703111248550.17073@theoryx5.uwinnipeg.ca>
	 <87tzwrzj8l.fsf@gemini.sunstarsys.com>
	 <87ps7fzf4d.fsf@gemini.sunstarsys.com>
	 <Pine.LNX.4.64.0703111457460.20950@theoryx5.uwinnipeg.ca>
	 <87hcsrzb0z.fsf@gemini.sunstarsys.com>
	 <877itnz3ei.fsf@gemini.sunstarsys.com>

On 3/12/07, Joe Schaefer <joe+gmane@sunstarsys.com> wrote:
> > Ok, lets presume DeleteFile() is failing, and passing
> > that error along to apr_file_remove().  In apreq_file_cleaup
> > let's then try what cygwin does in its unlink implementation:
> > opening the file again (using the apr API) with the APR_DELONCLOSE
> > flag set, then immediately closing it.
>
> Here's a different suggestion to try:
>
> Index: library/util.c
> ===================================================================
> --- library/util.c      (revision 517052)
> +++ library/util.c      (working copy)
> @@ -816,10 +816,6 @@
>         return rc;
>
>     data = apr_palloc(pool, sizeof *data);
> -    /* cleanups are LIFO, so this one will run just after
> -       the cleanup set by mktemp */
> -    apr_pool_cleanup_register(pool, data,
> -                              apreq_file_cleanup, apreq_file_cleanup);
>
>     /* NO APR_DELONCLOSE! see comment above */
>     flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY;
> @@ -828,10 +824,11 @@
>      * a grep through the httpd sources seems to indicate
>      * it's only used in sdbm files??
>     */
> -#ifdef WIN32
> -    flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
> -#endif
>     rc = apr_file_mktemp(fp, tmpl, flag, pool);
> +    /* cleanups are LIFO, so this one will run just before
> +       the cleanup set by mktemp */
> +    apr_pool_cleanup_register(pool, data,
> +                              apreq_file_cleanup, apreq_file_cleanup);
>
>     if (rc == APR_SUCCESS) {
>         apr_file_name_get(&data->fname, *fp);
>
>
> 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.

Here's what I get to see with filemon(from sysinternals) when I run
with my second patch(removing only the #ifdef win32 part):
** first apr_file_mktemp->apr_file_open->CreateFile **
12:33:59.625 AM	httpd.exe:4032	IRP_MJ_CREATE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS	Options: Create
Access: 0012019F

** then after all the reads and writes etc.. finally, apr's
file_cleanup->CloseHandle **
** presense of IRP_MJ_CLEANUP in here indicates that the filehandle
count is zero. **
12:35:29.281 AM	httpd.exe:4032	IRP_MJ_CLEANUP	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS
12:35:29.281 AM	httpd.exe:4032	IRP_MJ_CREATE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS	Options: Open
Access: 00120189
12:35:29.281 AM	httpd.exe:4032	IRP_MJ_SET_INFORMATION
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS	FileBasicInformation
12:35:29.281 AM	System:4032	IRP_MJ_CLEANUP	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS
12:35:29.281 AM	System:4032	IRP_MJ_CLOSE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS
12:35:29.281 AM	httpd.exe:4032	IRP_MJ_CREATE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS	Options: Open
Access: 00000180
12:35:29.281 AM	System:4032	IRP_MJ_CLEANUP	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS
12:35:29.281 AM	System:4032	IRP_MJ_CLOSE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS
12:35:29.281 AM	httpd.exe:4032	IRP_MJ_CLOSE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS


** After that apreq_file_cleanup->apr_file_remove->DeleteFile **
** DeleteFile does this: open the file of the given name, mark it for
deletion, close the file. **
12:38:10.218 AM	httpd.exe:4032	IRP_MJ_CREATE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS	Options: Open
Access: 00010080
12:38:10.218 AM	httpd.exe:4032	IRP_MJ_SET_INFORMATION
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS	Delete
12:38:10.218 AM	httpd.exe:4032	IRP_MJ_CLEANUP	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS
12:38:10.218 AM	httpd.exe:4032	IRP_MJ_CLOSE
	C:\DOCUME~1\pi\LOCALS~1\Temp\apreqq4EH3d	SUCCESS


Notice that interchanging the order of above two cleanup functinons
has no change in the final result. You either close the
file(CloseHandle) and then mark the file for deletion(DeleteFile) or
mark the file for deletion and then close the file, it's all the same.
The file will go if there were no other file handles(say, from inside
perl content handler that ran just before) holding on to it.

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.

Thanks,
Vinay Y S