-------- 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. > 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. > 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. For the userland (in fact everything but the file system itself) hardlinks simply look and can be handled like identical files, which is why I can't see any problem with the userland API (at least not in this respect). CU, Ingo