On Mon, Aug 04, 2003 at 01:10:14PM -0700, Jason Zions wrote:
> And you can still get there, even in a multithreaded app. If your app is
> knowingly doing this kind of thing, it can just as "knowingly" deal with
> the fact that fchdir() is being called and protect itself accordingly.
Sure.
> Are you guys seriously suggesting a new family of API calls (one for
> every call that takes a pathname) to specify the directory to which a
> relative path is in fact relative simply to handle some very obscure
> corner cases that can't be addressed by the use of absolute paths?
I think that there are only some very obscure corner cases if you limit
yourself to the ancient way to think about the filesystem, as a global,
system-wide hierarchical tree of nodes.
I want to encourage you to think about a filesystem as an object server, and
about files and directories as objects. Then it becomes apparent that it is
useful to be able to specify the object from which you want to start a
relative path lookup. Also, it becomes apparent that a global default
object is somewhat restricting in a multi-threaded environment.
It also makes something else apparent: Nobody says that there only can be
one "root" object from which all other objects can be accessed. Having
multiple such root objects is immediately useful, in fact, every directory
could become a root object (think of "chroot"). The idea of process based
filesystems views have become core elements of new operating systems
(Plan 9, Vsta), and there are other consequences that are highly desirable
(such object based systems usually work via capabilities instead ACLs, which
allows higher security - the whole idea of privilege seperation that BSD is
now looking at is actually pretty old and naturally implemented in such
systems).
If you have highly flexible "views" on the filesystem, having nodes that can
not be accessed from the global default root can be something pretty normal,
rather than the obscure corner case.
What are the consequences for Austin? For now, probably none. I don't see
an immediate need to standardise such more flexible interfaces, which would
be based on a different, more modern way to look at filesystems. However,
it should be realized that such more modern implementations must provide the
flexibility, and do so by non-standard APIs. Maybe in 10 years or so this
more modern way to look at filesystems is so common that a common API is
desirable, and then something common might emerge. Until then, I guess that
in the simple cases you can go for the standard, limited API and for the
more interesting cases you have to use something non-standard.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org yyyyyy@xxxxxxx
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
yyyyyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxx
http://www.marcus-brinkmann.de/
|