[Top][All Lists]

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

Re: Unionmount. Basic details

From: olafBuddenhagen
Subject: Re: Unionmount. Basic details
Date: Sun, 26 Apr 2009 22:48:13 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


On Sat, Apr 11, 2009 at 03:03:45PM +0200, Carl Fredrik Hammar wrote:
> On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:

> > Also, I'm not aware of anybody still doing any changes to unionfs
> > :-)
> Also, in many ways unionfs seems like an good candidate to make use of
> libmob which I'm working on.  Making that that change would hopefully
> not be too extensive, but it would not be trivial.

The changes necessary to handle mobility most likely won't touch the
actual merging code, but rather all the other stuff regarding startup
etc. -- i.e. exactly the stuff that will differ between unionmount and
unionfs anyways.

Also, as a general rule, it is a *very* bad idea to base current design
decisions on possible future prospects... A typical case of YAGNI.

> There is one more route you may want to consider.  As I mentioned in
> my replies to antrik, unionmount is basically anonymous file systems +
> unionfs.  You could write a utility to handle anonymous file systems
> instead. Even if it turns out that a specific unionmount with special
> rules is needed, we'd still get a very useful utility out of the
> process.

While I think this is a very interesting direction to pursue, it's still
very vague. As I already said, I think it's much easier to factor out
the common functionality once we have working code for the various use
cases, and know exactly what is required.


reply via email to

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