Hello, On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote: > On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@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