Re: News 2009-08-31

[Sergiu Ivanov]

Hello,

On Sun, Sep 06, 2009 at 03:20:04PM +0200, Arne Babenhauserheide wrote:
> Am Sonntag, 6. September 2009 13:30:46 schrieb Sergiu Ivanov:
>
> > I'm inclined to occupy a similar position.  However, I'd say that we
> > somehow failed to discuss how exactly to make the code public :-( Of
> > course, I can just create a master-unionmount branch in the unionfs
> > repository, but I'm not sure antrik will approve of that.  OTOH, I
> > could push my repository to something like github.
> 
> Can't you just push it to github first and then integrate it cleanly once we 
> decided how to do that? 

git://github.com/scolobb/unionmount.git

Please note that syncing may not work as expected in this variant,
since the problem with implementing the corresponding libnetfs stubs
in unionfs in the master branch has not been solved yet.  Other parts
of unionmount should be working pretty well.
 
> > The usage of unionmount is simple:
> >
> >  $ settrans -a <node> unionfs -ut <translator>
> >
> > This will union-mount <translator> on <node>.
> 
> -snip-
> 
> > Also (if required) I can provide a short explanation on some Hurd wiki
> > page.  
> 
> That would be great! 
> 
> Ideally with some nifty examples what we can do with your translator :) 
> (examples make docs far easier to understand). 

OK, I'll do that.  There is a small problem though: I'm not sure on
which page to create the documentation.  There is
hurd-web/hurd/translator/unionmount.mdwn, but it's the description of
the project idea.

antrik, is it okay if I add the short documentation about the usage of
union-mount-mode options in unionfs to this page?
 
> > This will take less time than writing full-fledge documentation
> > (which means that I'll be able to do it much sooner) and should be
> > enough for the majority of use-cases.
> 
> Maybe you can also use it as starting point.  Then you won't have to write 
> everything over again, but can just reuse the short description to turn it 
> into full fledged docs later on. 

Yeah, that's a good suggestion, thanks :-)
 
> > [...] both unionfs and nsmux were designed to be stand-alone,
> > i.e. building unionfs and nsmux basically resumes to getting the
> > code and running make.
> 
> Does that mean, I could just do 
> 
>       git clone <future unionfs repo> unionfs
>       cd unionfs
>       ./configure
>       make
>       settrans -a shared unionfs -ut ftp / ftp.gnu.org
> 
> to union the files from ftp into my own dir? 

Yep, but unionfs does not use autotools, so you don't need
./configure.  Otherwise, everything should be okay.

I haven't used ftpfs, though, so I can't say I am 100% sure it will
work; I'd say it's around 95% that it will work out of the box.  The
problem is that unionmount is very much sensitive to any apparently
minor misbehaviour of the mountee (choosing weird inode numbers for
one), so things might break mysteriously.  If you experience anything
like that, announce me, please.

> Where will changed files be written in that case? In the dir where
> they originate?

It depends on the type of the change you are doing.  A directory will
be created in all underlying filesystems; a similar behaviour will
happen at file and directory removal.  A file will be created in the
first filesystem which does not return error on a file_name_lookup
with O_CREAT flag.  File content modifications will go in the first
filesystem in which the file was successfully looked up.

I hope I've given an understandable explanation; if not, please ask
for more details :-)

Regards,
scolobb