Re: unionfs Documentation

[Sergiu Ivanov]

Hello,

On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote:
> On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafBuddenhagen@gmx.net wrote:
> > On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> 
> Sergiu, then please remove the shadowfs reference(s) from the GNU
> Hurd Reference Manual.

Could you please tell me how is the GHRM maintained?  Is there a git
repository or something like that?  Or is it a single file?
 
> Sergiu, please address Olaf's valid comments as much as you want,
> put the unaddressed ones into the file (commented-out, like: ``Olaf
> Buddenhagen: rather say s.th. like ...''), and put it into the
> unionfs repository.  Don't spend too much time on the build
> infrastructure; I'll take care of that as soon as I do the overall
> Automake dance.
 
Should I go this way, what name for the file should I chose?  unionfs
already has a README, so something different (like ``DOCUMENTATION''
or ``README.LONG'') is required.
 
> > > @item -u
> > > @itemx --underlying
> > > Add the underlying file system to the list of union mounted file
> > > systems.
> > > 
> > > @item -w
> > > @itemx --writable
> > > Specify the following file system as writable. This makes it possible
> > > to create new nodes in the specified file system.
> > 
> > Are these two really only possible on startup? Seems like a major
> > limitation, which should be fixed...
> 
> If yes, then this is worth either a item in the Savannah task list, a new
> *open issue* in the web pages, or an entry in a TODO file in the unionfs
> repository.

As I pointed out in an other E-mail, I classified the options
erroneously, so no new issues are required as far as this detail is
concerned.
 
> > > @item
> > > If there's a name conflict in underlying file systems between
> > > directories (or between files), and the user has no permission to
> > > delete all the entries -- e.g. one hidden entry is read-only -- then
> > > he will get an @samp{EPERM} even if permissions seems ok. This is a
> > > structural bug (there's no clean way to solve it), and should be
> > > fixed.
> > 
> > I think both of these problems are actually a result of handling file
> > deletion fundamentally wrong; or perhaps even handling writable entries
> > wrong in general. It's probably never right to write to more than one
> > directory at a time.
> > 
> > This is a non-trivial problem. Other unionfs implementations probably
> > spent considerable time figuring out how to do it best. I entreated
> > Gianluca to check what over implementations do, instead of trying to
> > reinvent the wheel -- but he wouldn't listen :-(
> 
> This for sure has been ``solved'' (in one way or another) by now in other
> designs and implementations.  Some weeks ago I added a few links to some
> Linux unionfs pages to our unionfs web page.  Someone could go looking
> there.

Oh yeah, this someone should be me.  I think I'll do that shortly.
 
Regards,
scolobb