Re: Fallthrus as full-length symlinks?

[Valerie Aurora <vaurora@redhat.com>]

On Tue, Nov 17, 2009 at 03:03:07AM -0500, AYAN TYAGI wrote:
> On Tue, Nov 17, 2009 at 1:44 AM, Jamie Lokier <jamie@shareable.org> wrote:
> > AYAN TYAGI wrote:
> >> > >Another idea that I first had when reading the suggestion was to use a
> >> > >symlink to self (ln -s x x) as the encoding for a fallthrough. It does
> >> > >not allow renames like what you really describe, but it has another advantage
> >> > >in that it does not require extensions to the upper file system layout
> >> > >while not conflicting with any use case I can see.
> >>
> >> It seems to be a great idea to make use of self referenced symlinks .
> >> Could you please describe the whole process u are proposing?
> >>
> >> If possible give some example and code .
> >
> > That'll do surprising things when the user _really_ makes a
> > self-referencing symlink with "ln -s x x", which can happen
> > unexpectedly, for example by untarring some archive.
> >
> > If a fallthrough is encoded that way, there should probably be an
> > error when the user tries to make a self-referencing symlink.
> >
> > -- Jamie
> >
> 
> >> > The interesting thing about
> > > >this idea is that it could theoretically let us rename a file from the
> > > >low level file system to another place in the low-level file system
> > > >without copying the contents of the file up.  Basically, we can
> > > >arbitrarily swizzle the namespace of the low-level by maintaining a
> > > >set of symlinks above.
> 
> So do you mean that the need of copyup in case of renaming is
> virtually eliminated ?

Only in the case of an unaltered file from the read-only layer being
renamed to a directory that exists in the read-only layer as well.  I
suspect this is not a common case, and most rename()s occur on newly
created files.

-VAL