[Top][All Lists]

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

Re: DogCows or Polymorphism in the Hurd

From: Jonathan S. Shapiro
Subject: Re: DogCows or Polymorphism in the Hurd
Date: Mon, 06 Feb 2006 11:49:16 -0500

On Mon, 2006-02-06 at 11:33 +0100, Patrick Negre wrote:
> I apologize for my bad english.
> > > Is it really a good idea to create new name in the filesystem tree ? I
> > > mean, a file must have only one path, create new nodes with binding is
> > > confusing.
> >
> > Why must a file only have one path? This seems like a completely
> > artificial and unnecessary restriction.
>   Yes, you are right "Must" is a little bit strong.
> But, (correct me if i'm wrong) if a program ( view_1.exe ) open "thing.xml" 
> with a dir facet , then the directory "thing" is created in the fs. 
> Suppose an other program ( view_2.exe ) open the same file with a file facet 
> "sort", then a file "thing.sort" is created in the fs. 
> So, as a user if i explore the directory i will see 3 objects which are the 
> same, and if view_1.exe exits then the directory desapear, and same thing if 
> view_2.exe exits. 

I think that we are talking about usage models, and I think that we are
talking past each other. Let me talk only about your view1.exe -- more
views will make things complicated, and we only need one "extra" view to
figure this point out.

First, I believe that running "view1.exe" and binding a name to that
view might be two different decisions. I am not sure if the user
interface should make them happen as one thing or not. I have observed
in Windows that *failure* to make them one thing creates real problems.

Second: if the directory facet *does* get a bound name, then view1.exe
does not exit (or alternatively it is restarted on demand). As long as
this is the case there is no confusion.

>    In a user point of view, i think it will be confusing, and even not wanted.
> In the case of a view used only by programs, the user didn't need or want to 
> have the corresponding file in his fs.

It is needed by programs more than by users. It is the programs that are
trying to access using paths, and therefore need the binding.

>    Isn't the following case possible ? When a program, wanna access a file, 
> according to the filetype there are several translator that manage a facet 
> for the file. The program choose the facet it need and after that communicate 
> with the corresponding translator. That mean, programs can have a different 
> sub-filesystem rooted at the file if they access it with different 
> translator.

Yes, this is possible for programs that are aware of facets, but our
original conversation concerned what to do for *unaware* POSIX

Crud. I intended this for the list....

Even for programs that are aware, this doesn't solve the real problem.
The real problem is that the usage pattern you propose is fundamentally
ambiguous. You have successfully moved the ambiguity to another place in
the design, but I don't think you have solved it.

> > In the case of the Windows setup.exe example, the problem is that setup
> > discovers the location of the distribution directory by computing the
> > path to the setup.exe binary, so if you have
> >
> > foo/bar/setup.exe
> >
> > the setup program assumes that the rest of the installation is described
> > by a file
> >
> > foo/bar/setup.ins
> I think setup.exe will need to access ./setup.ins. So that put no constraint 
> over the name of the containing directory, so it can be 
> "foo.tar.gz/bar/setup.ins", isn't it ?

This is approximately what happens right now, and it is why the
installer fails -- at the FS open() interface, the system doesn't really
know that foo.tar.gz has any sort of decompressed directory facet.

> And, how this problem is handled by the system :
> Consider a file "foo.gz" that contain 2 file "a.txt" and "b.txt".
> Suppose a program "p1.exe" open "foo.gz/a.txt" with a translator
> and want an exclusive access to the file.
> Suppose a program "gzip" open "foo.gz," and want to update it, whith a fresh 
> "b.txt".Then, gzip need access to rewrite "foo.gz", and then a write access  
> to "foo.gz/b.txt", and that is forbidden by "p1.exe" request.
> But, gzip don't want to modify "foo.gz/b.txt", so his request don't  hurt the 
> "p1.exe" request.
> How the contradiction is resolved ?

This is a general problem in maintaining consistent views. In this case
I think that an answer is possible, but I don't have time to think it
through. In general, I'm not sure that perfect consistency is possible.


reply via email to

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