[haiku-development] Re: BFS's Lack Of Support For link() - hard links

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 18 Nov 2009 13:18:13 +0100

-------- Original-Nachricht --------
> Datum: Wed, 18 Nov 2009 09:07:50 -0200
> Von: Bruno Albuquerque <bga@xxxxxxxxxxxxx>

> 2009/11/18 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >
> > -------- Original-Nachricht --------
> >> Datum: Wed, 18 Nov 2009 08:22:15 -0200
> >> Von: Bruno Albuquerque <bga@xxxxxxxxxxxxx>
> >
> >> 2009/11/18 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >>
> >> >> Dominic was talking about handling things like queries, for example.
> >> >> It was the user experience, not the lack of a link() implementation
> >> >> that would not be done in time.
> >> >
> >> > I can't see the problem you're referring to regarding queries or the
> >> user experience. link() was implemented in BeOS (and is in Haiku) and
> worked
> >> just fine. At least in with my RamFS queries worked as one would
> expect.
> >>
> >> One of the problems is that queries return nodes.
> >
> > Nope, they return entries.
> 
> I guess you misunderstood me (probably my fault as I said node when I
> meant i-node). Indexes stores references to i-nodes. The i-node has
> its own name and a reference to the parent. Given an i-node, you need
> to construct the path (as it is not readily available) by iterating
> back through the parent reference, getting its name, then repeating
> until you have the full path. Now imagine this scenario:
> 
> a/b/1
> c/d/2
> a/e/3
> 
> a, b, c, d, and e are directories and 1, 2 and 3 references the same
> file (hard links). If there is an attribute/index pair that causes
> those files to be indexed, 2 things could happen:
> 
> 1 - You only index one of the references. In this case if that
> reference would be deleted, the other 2 would still be valid but not
> be present in the index (for example. There are probably other related
> problems).
> 
> 2 - You index the 3 references. As they are all the same inode, only a
> single path can be constructed back so, effectively the path of the
> other 2 entries would be wrong. Of course you could just say that this
> is expected behaviour as they are all the same file but, then, if you
> delete the reference that happened to be in the correct path... Well,
> you see the problem.
> 
> The problems above could be solved by some creative programming, of
> course, but doing it right may be complicated (specially because the
> definition of right in this case is very subjective).

I'm not sure what your point is here. Yes, BFS (particularly it's on disk 
structures) doesn't support hardlinks and it would have to be changed to do 
that. And yes, one could do right or wrong. I'd favor the former.

> >> When you have a hard
> >> link, you have 2 (or more) entry points in the filesystem for the same
> >> node. The nodes are converted to paths by looking at the parent and
> >> constructing the path based on that. But what would be the correct
> >> parent to use? Which of the entries in the fs would be used to
> >> reconstruct the path?
> >
> > Since entries, not nodes, are returned, there's no problem here.
> 
> Again, mea culpa. I meant i-nodes and the fact that a refernce to them
> is what is stored in the indexes.

Still not a problem of the userland API (or any component other than BFS).

> >> You may have solved it in your RamFS but for Be
> >> to do that it would  have needed extensive testing including user
> >> feedback, which takes time.
> >
> > Well, features always take some time to test, but unlike Dominic stated
> there's no fundamental problem with (or missing feature in) in the C++ API,
> only in BFS.
> 
> The problem was a matter of user experience. When he said the C++ API
> did not support it he meant that the C++ API was not ready to handle
> the cases like what I described above. The behavior with hard links,
> had they been implemented, would be essentially broken in the userland
> API.

Which is just wrong. Hardlink support, correctly implemented in the FS, does 
not cause problems in the userland. Incorrectly implemented hardlink support 
would, but then blaming the userland C++ API for that is just weird reasoning.

CU, Ingo

Other related posts: