Hi, 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. -antrik-
