Now that --modtime is supported it's possible for a cached invocation to become functionally unreachable[^1] but remain in the cache for an extended period of time. For example:
bkt --ttl=1d --modtime=.git/FETCH_HEAD -- git status
Any cached status will become unreachable whenever FETCH_HEAD is updated (i.e. after git fetch / git pull) but presently bkt can't actually clean up the data until the TTL expires. In principle bkt could clean up all existing cached data linked to a given file whenever its modtime changes.
Furthermore, if this functionality is added such commands could be allowed to not set a TTL at all (if they want) and simply rely on modtime invalidation.
This would be a somewhat sizable refactoring of the Bkt and Cache APIs, but it's probably worth the effort.
[^1]: yes a file could theoretically be set to a prior modtime, either manually or after a clock change, but this is uncommon and a cache miss in such circumstances is probably acceptable.
Now that
--modtime
is supported it's possible for a cached invocation to become functionally unreachable[^1] but remain in the cache for an extended period of time. For example:Any cached
status
will become unreachable wheneverFETCH_HEAD
is updated (i.e. aftergit fetch
/git pull
) but presentlybkt
can't actually clean up the data until the TTL expires. In principlebkt
could clean up all existing cached data linked to a given file whenever its modtime changes.Furthermore, if this functionality is added such commands could be allowed to not set a TTL at all (if they want) and simply rely on modtime invalidation.
This would be a somewhat sizable refactoring of the
Bkt
andCache
APIs, but it's probably worth the effort.[^1]: yes a file could theoretically be set to a prior modtime, either manually or after a clock change, but this is uncommon and a cache miss in such circumstances is probably acceptable.