[PATCH 0 of 2 RFC] auditing paths on flag changes

[Matt Mackall]

On Sun, 2011-05-22 at 00:32 +0200, Adrian Buehlmann wrote:
> I'll most likely get a layering violation brown bag from Matt for this.

Actually, no, I don't see a problem with this.

> We probably need to have a design chat about which audit cache should
> be used for what tree.
> 
> My understanding is, that the cache of the auditor of the repo's wopener is
> conceptually tied to _the tree we're updating to_ (on 'hg update').

Not sure what you mean by 'tree' here. You seem to be suggesting the
directory state at a given revision. But it's really just attached to
the working directory. 

Now, it may be the case that the cache can get confused if it persists
across multiple updates, and we should be nuking it across working
directory 'transactions' (ie periods where we hold the wlock). But other
than that, the fact that a cache exists shouldn't be a visible
implementation detail.


(We could have another long discussion about whether we should be paying
attention to the TOCTOU exploits possible here that could be exploited
by hostile local users with write permissions in the working directory.
But my general approach here is that once you've given a local hostile
user write permissions in your working directory, you've already lost so
we can ignore all -local- coherency issues for the purposes of the
cache.)

> But we might have a problem already with the current design: What happens if
> someone uses the same localrepo object for multiple operations (e.g. multiple
> updates)?
> 
> merge.applyupdates currently uses a local transient auditor for files that are
> unlinked. Which is good because thanks to this, these paths won't be added
> to the auditor's cache of localrepo.wopener. But is this enough? Can't these
> paths already be lingering in the auditor's cache of localrepo.wopener from earlier
> file accesses?
> 
> Shouldn't we remove the paths of the files we are unlinking from the auditor's
> cache?
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel


-- 
Mathematics is the supreme nostalgia of our time.