On 02/02/2013 10:03 AM, Eliezer Croitoru wrote: > On 2/2/2013 5:10 PM, Luciano Ruete wrote: >> Ok, this one is my fault. Debian/Ubuntu init script does a squid -z in a >> pre-start hook if the cache_dir was not initialized. My rock cache_dir >> was already initialized but the script only knows from AUFS and COSS >> because it is ready for squid-3.1 and not for squid-3.2. > I think that like in ufs case squid -z should not reset the rock store > file and just recreate it if it's not there. ufs checks the presence of the configured directory, not any individual files inside that directory. For consistency, if rock -z behavior is changed, rock should do the same (current rock code uses a single file inside the configured directory, but that is an implementation detail that might change -- we may even support raw partitions some day). > The reason is to be consistent with ufs and also prevent this kind of > problem. The cause of this specific problem is _not_ rock behavior (correct or not) but a mismatch between a startup script and squid.conf -- the script does not test for all the right directories when running squid-z. Even if rock code is changed, this mismatch still needs to be fixed. Please consider filing a bug report with Debian/Ubuntu if it is their fault. To be consistent with ufs, we should probably change rock behavior from initializing the database to doing nothing if the configured database directory already exists. Like ufs, rock will rely on directory existence for that test (regardless of what may be inside that configured directory). In other words, squid-z is not "validate and initialize" but "initialize if the configured directory is not there". Any objections to that rock change? Thank you, Alex.
