Moritz Schulte announced that he has stopped working on the ShadowFS file system for the GNU/Hurd. Instead, he has begun working on a new, better designed filesystem under the name UnionFS, a name change suggested by Richard Stallman. Moritz says, "Compared with my former implementation, this one uses a completely new design approach."

One major improvement UnionFS offers over his previous ShadowFS implementation is the addition of caching. A second improvment is that you can now add and remove directory trees from/to the united tree during runtime with the fsysopts program, even the tree that underlies the node where UnionFS itself sits. The current code is still very much under development and certainly has its bugs and limitations, but seems to work well enough at least for some purposes when used in read-only mode.

From: Moritz Schulte
To: bug-hurd mailing list
Subject: Unionfs
Date: Sat, 07 Dec 2002 19:06:09 +0100

Hello,

  after not doing any work on my former shadowfs implementation
anymore for many months, I started working on a new implementation
(`unionfs') few weeks ago.  It is quite uncomplete at the moment and
has not few problems.  Compared with my former implementation, this
one uses a completely new design approach.

  I have just checked in my latest sources into the Hurd Extras CVS
repository; it can be checked out with the command:

 $ cvs -d:anoncvs@subversions.gnu.org:/cvsroot/hurdextras co unionfs

Have fun/Happy hacking.

Thanks,
                moritz

_

From: Wolfgang Jaehrling
To: bug-hurd mailing list
Subject: Re: Unionfs
Date: Sun, 8 Dec 2002 08:35:21 +0100

On Sat, Dec 07, 2002 at 07:06:09PM +0100, Moritz Schulte wrote:
> Have fun/Happy hacking.

I was just playing around with it a bit and glancing over the code;
when compiling, I got the messages:

gcc -o unionfs main.o node.o lnode.o ulfs.o options.o 
  ncache.o netfs.o lib.o -lnetfs -lfshelp -liohelp -lthreads 
  -lports -lihash -lshouldbeinlibc
/usr/bin/ld: netfs.o(.debug_info+0x6399):
  unresolvable relocation against symbol `_netfs_translator_callback1'
/usr/bin/ld: netfs.o(.debug_info+0x63ac):
  unresolvable relocation against symbol `_netfs_translator_callback2'

However, it did work nevertheless (i.e. the unionfs binary was created
and could be started).

I noticed that lnode_ref_remove() and lnode_uninstall() recursively
call each other, where lnode_uninstall() calls lnode_ref_remove() on
node->dir, which should be locked; I could not find anything that
indicates that it will be.

Also, I find it a bit unfortunate that a simple `ls' triggers this
already:

wj@hurd:~/unionfs$ settrans -ac foo unionfs .. /
wj@hurd:~/unionfs$ ls foo/unionfs/
ls: foo/unionfs/foo: Too many levels of symbolic links

And of course, I just had to try compiling Unionfs inside of a
Unionfs. :-) The result was:

wj@hurd:~/unionfs/foo/unionfs$ make
make: getcwd: : No such file or directory
gcc -Wall -g -D_FILE_OFFSET_BITS=64 -std=gnu99 -DDEBUG -c main.c
Assembler messages:
FATAL: can't create main.o: Invalid argument
make: *** [main.o] Error 1

More feedback coming soon.

Cheers,
GNU/Wolfgang

_

From: Moritz Schulte
To: bug-hurd mailing list
Subject: Re: Unionfs
Date: Sun, 08 Dec 2002 09:04:11 +0100

Wolfgang Jaehrling writes:

> /usr/bin/ld: netfs.o(.debug_info+0x6399): unresolvable relocation
> against symbol `_netfs_translator_callback1'

I am not sure what this is; I don't see it here.

> I noticed that lnode_ref_remove() and lnode_uninstall() recursively
> call each other, where lnode_uninstall() calls lnode_ref_remove() on
> node->dir, which should be locked; I could not find anything that
> indicates that it will be.

Hmm, I will look into that.

> Also, I find it a bit unfortunate that a simple `ls' triggers this
> already:
>
> wj@hurd:~/unionfs$ settrans -ac foo unionfs .. /
> wj@hurd:~/unionfs$ ls foo/unionfs/
> ls: foo/unionfs/foo: Too many levels of symbolic links

Of course; that is exactly the problem we were speaking about on IRC.
If you would be allowed to lookup foo/unionfs/foo, this would lead to
endless recursion - wouldn't be so nice for e.g. the locatedb-find
process.

Thanks for your comments.

                moritz

_

From: Wolfgang Jaehrling
To: bug-hurd mailing list
Subject: Re: Unionfs
Date: Sun, 8 Dec 2002 09:17:33 +0100

On Sun, Dec 08, 2002 at 09:04:11AM +0100, Moritz Schulte wrote:
> > Also, I find it a bit unfortunate that a simple `ls' triggers this
> > already:
> >
> > wj@hurd:~/unionfs$ settrans -ac foo unionfs .. /
> > wj@hurd:~/unionfs$ ls foo/unionfs/
> > ls: foo/unionfs/foo: Too many levels of symbolic links
>
> Of course; that is exactly the problem we were speaking about on IRC.
> If you would be allowed to lookup foo/unionfs/foo, this would lead to
> endless recursion - wouldn't be so nice for e.g. the locatedb-find
> process.

Still, I find it a bit unfortunate that a simple `ls' triggers this
already. ;-)

How about giving it the appearance of an empty directory instead?
Then dired mode and `ls -l' etc. would not fail when looking at the
parent directory of the node in question; I don't think it would cause
any harm.

Cheers,
GNU/Wolfgang