You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
verrou_dd only invalidates its cache when the run-script or the cmp-script change. But these scripts usually recursively call other binaries or touch configuration files which verrou_dd has no knowledge of. Therefore, the dd.sym cache is often reused when it shouldn't be.
I propose two possible strategies to deal with this, a sane but unsatisfying one an a less sane but more powerful strategy:
Sane-but-meh option: Invalidate the cache by default when a top-level verrou_dd command is run. If the command calls itself recursively, make sure that the recursive invocations do not invalidate the cache. This can be done by adding an optional "--reuse-cache" script option, which will also allow users who know what they are doing to reuse a cache from a previous run.
Insane option: In principle, one could strace run-script or cmp-script calls in order to tell which files the run_script and cmp_script recursively depend on, and then compute a hash of them to detect dependency changes... ^^
The text was updated successfully, but these errors were encountered:
verrou_dd only invalidates its cache when the run-script or the cmp-script change
Please note that even this simple heuristic is not used currently. At the moment, Verrou never invalidates its cache which, as you note, is not a good idea as it misleads users most of the time.
I would be in favor of implementing your 'sane-but-meh' option in a first stage, then see whether more is needed. We also have a few ideas regarding helper scripts which could allow (advanced) users to invalidate only parts of the cache. For example: invalidate successful tests if a verrou_dd error reveals that VERROU_DD_NRUNS was set to a too small value).
verrou_dd only invalidates its cache when the run-script or the cmp-script change. But these scripts usually recursively call other binaries or touch configuration files which verrou_dd has no knowledge of. Therefore, the dd.sym cache is often reused when it shouldn't be.
I propose two possible strategies to deal with this, a sane but unsatisfying one an a less sane but more powerful strategy:
The text was updated successfully, but these errors were encountered: