You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2012/10/08 02:37:32 UTC

Re: disk cache file rename errors on Windows

On Thu, Dec 2, 2010 at 12:23 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 23 Nov 2010, at 8:21 PM, Dan Poirier wrote:
>
>> We're seeing errors like this from mod_disk_cache on Windows only:
>>
>> (OS 5)Access is denied.  : disk_cache: rename tempfile to datafile
>> failed: c:/temp/HTTPServer7/aptmpV0JKJ8 ->
>> c:/temp/HTTPServer7/wHY/FhW/b5uD@MuvttLK@V4w.data
>>
>> under moderate to heavy load, resulting in requests failing.
>
>
> Looking at the code, the error message is thrown when apr_file_rename()
> fails, specifically when a temporary file is swung into place in the cache.
>
> Looking at the APR code, there is a forest of ifdefs that seem to choose one
> of MoveFileEx(), MoveFileW(), MoveFileExW() or MoveFile(). Ideally, the
> Microsoft API documentation should explain under what conditions the error
> "Access is denied" is thrown.
>
> Does Windows allow you to move a file into place while the replaced file is
> still open for read?

This may have been a red herring.

When a revalidation fails, mod_disk_cache still has an open handle to
the data file, but will be called on to create a new tmpfile and copy
it on top of that very same datafile.

Index: modules/cache/mod_cache_disk.c
===================================================================
--- modules/cache/mod_cache_disk.c	(revision 1395428)
+++ modules/cache/mod_cache_disk.c	(working copy)
@@ -596,6 +596,11 @@

 static int remove_entity(cache_handle_t *h)
 {
+    disk_cache_object_t *dobj = (disk_cache_object_t *) h->cache_obj->vobj;
+    if (dobj->fd != NULL) {
+        apr_file_close(dobj->fd);
+    }
+
     /* Null out the cache object pointer so next time we start from scratch  */
     h->cache_obj = NULL;
     return OK;

This fixes the error in the OP for me, but if it were right you'd
think it would be a problem outside of windows during failed
revalidations.  It seems like in the normal path where the datafile is
opened, it is closed somewhere under the covers by virtue of being
used in a file bucket written out to the client.  But there seems to
be no hope for this fd if it's not written to the client.