https://issues.apache.org/bugzilla/show_bug.cgi?id=50317
--- Comment #47 from Ruediger Pluem <[email protected]> --- (In reply to jkaluza from comment #46) > I have good results with following patch (on top of the patch in Comment 41): > > diff --git a/modules/cache/mod_disk_cache.c b/modules/cache/mod_disk_cache.c > index 13d6c8b..305fa6b 100644 > --- a/modules/cache/mod_disk_cache.c > +++ b/modules/cache/mod_disk_cache.c > @@ -962,15 +962,6 @@ static apr_status_t store_headers(cache_handle_t *h, > request_rec *r, cache_info > > apr_file_close(dobj->hfd); /* flush and close */ > > - /* Remove old file with the same name. If remove fails, then > - * perhaps we need to create the directory tree where we are > - * about to write the new headers file. > - */ > - rv = apr_file_remove(dobj->hdrsfile, r->pool); > - if (rv != APR_SUCCESS) { > - mkdir_structure(conf, dobj->hdrsfile, r->pool); > - } > - > rv = safe_file_rename(conf, dobj->tempfile, dobj->hdrsfile, r->pool); > if (rv != APR_SUCCESS) { > ap_log_error(APLOG_MARK, APLOG_WARNING, rv, r->server, > > I think the race condition exists between this apr_file_remove and > safe_file_rename. There is no cached file between these two calls. > safe_file_rename should overwrite any existing file with the same name, so > there's no need for apr_file_remove imho. Agree for Linux (possibly all UNIX systems). Looking at the APR Windows code I think that this should work as well (having an atomic operation if the target file already exists and causing it to be replaced by the source file). Can someone of the Windows guys please crosscheck? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
