On Thu, Dec 2, 2010 at 12:23 PM, Graham Leggett minf...@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@muvt...@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.
