On Wed, Aug 06, 2014 at 07:41:31AM -0400, Greg Troxel wrote:
> [email protected] writes:
> > ls <conflict>/.codactl/replicas/
> > diff <conflict>/.codactl/replicas/{server1,server2}
> > diff <conflict>/.codactl/replicas/server1 <conflict>/.codactl/local
> > echo server2 > <conflict>/.codactl/prefer
> >
> > Which could possibly be worth to be available even if <conflict> is not a
> > conflict but a healthy file or directory, just in case, like "cfs expand".
>
> That in concept sounds good.
In concept, but in practice you now have a directory hardlink between
<conflict> and <conflict>/.codactl/local, and as such a path of infinite
recursion.
cfs expand does some tricky stuff to avoid this, under the covers it
tries to do the following (not actual steps since it can do this
atomically under the covers):
mkdir .tmp_conflict
cfs mkm .tmp_conflict/server1 @server1.object.replica
cfs mkm .tmp_conflict/server2 @server1.object.replica
mv <conflict> .tmp_conflict/localhost
mv .tmp_conflict <conflict>
This way there is no directory hardlink and in theory any open
references to files in <conflict> can stay open. (the problem for
active references is the step where we try to collapse <conflict>
into a dangling symlink to indicate that there is a conflict.
> I don't understand the notion of using xattr for control. They are
> extra properties stored on files, and it seems semantically abusive to
> write them as a control operation. (Having .codactl is also a bit
> abusive, but it's s single clean break.)
Not all are appropriate but from a quick scan the following would fit
very nicely with the concept of properties on files and/or volumes:
cfs setacl/listacl other filesystems also use xattrs for these
cfs getfid get the fid
cfs whereis get the replica server names/addresses
cfs listvol get the volume information
cfs getmountpoint get the nearest ancestor volume mount?
cfs lsmount read the contents of the covered mountlink
cfs listlocal show volume CML
Jan
