[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: News 2009-08-31

From: Arne Babenhauserheide
Subject: Re: News 2009-08-31
Date: Tue, 8 Sep 2009 12:52:28 +0200
User-agent: KMail/1.12.1 (Linux/2.6.30-hh2; KDE/4.3.1; x86_64; ; )

Am Sonntag, 6. September 2009 17:07:01 schrieb Sergiu Ivanov:
> git://github.com/scolobb/unionmount.git

I assume from the discussion, that this will not be the final destination.  Am 
I right in that? 

> 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.

-> to the description? 
> 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.

After seeing that the other translators are also described there, I'd say just 
add a section 

# What it does

above the project description and give the project description a title like 


# Initial project description

That way we can most easily refactor the text into another page and include 
that, similar to what is done for the tmpfs translator: 
-> http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html

> >     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.  

Sounds good! 

> 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.

I hope I'll get around to testing it in the not too distant future (need to go 
to my books, learning... ). 
> > 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 :-)

I think it's quite understandable. Many thanks! 

Best wishes, 

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]