[Unionfs] Strange behavior when adding a branch

[Shaya Potter]

Erez Zadok wrote:
> 
> Yoav/Shaya, it depends what users really want.
> 
> First, understand that there's little precedent to what Unionfs does.  In
> traditional posix OSs, a file or directory has a clear, unmistakable,
> single, unique location -- a one-to-one mapping of files to their locations.
> With Unionfs, however, you've got yourself a fan-out situation -- a
> one-to-MANY mapping of files to their locations.  Any time you have "MANY"
> to choose from, you have to answer the question "which one do I pick"?

....

> Folks, I don't mind changing Unionfs's semantics if that's what most user
> want.  But I'd like to hear that this is indeed what users want.  I don't
> want to make a change that will break the desired behavior for existing
> users who may depend on that behavior.  If the issue is confined to having
> two different ways in which unionfs might handle *open* files, then which
> one of them should we pick: stick with the old content or go for the new?
> Or maybe it should be a user option?  Ideally, I'd like to avoid having many
> different modes of operations to choose from at mount time.
> 

Users want to be able to run programs within Unionfs.  Running programs 
requires mmaping files.  Without the semantic we expect, mmap programs 
should break OR you have an inconsistent semantic.  If a file is opened, 
and a new version is placed to the left of it, it should be left as is, 
basically treated as if it was unlinked and a new version was created