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
