Path: utzoo!utgpu!watmath!att!dptg!rutgers!usc!cs.utexas.edu!uunet!intercon!amanda@intercon.uu.net
From: amanda@intercon.uu.net (Amanda Walker)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0
Message-ID: <1421@intercon.UUCP>
Date: 30 Aug 89 17:39:20 GMT
References: <227700026@uxa.cso.uiuc.edu> <483@sunfs3.camex.uucp> <9173@thorin.cs.unc.edu> <13784@shamash.cdc.com> <490@sunfs3.camex.uucp> <8368@hoptoad.uucp> <3214@zeus.unl.edu> <1394@intercon.UUCP> <3908@internal.Apple.COM> <1402@intercon.UUCP> <416@kunivv1.sci.kun.
Sender: news@intercon.UUCP
Reply-To: amanda@intercon.uu.net (Amanda Walker)
Organization: InterCon Systems Corporation
Lines: 22

In article <416@kunivv1.sci.kun.nl>, ge@kunivv1.sci.kun.nl (Ge' Weijers)
writes:
> I wonder why it is more difficult to implement file IDs than directory IDs.
> I suppose the problem is similar, especially in systems where directories
> are implemented as files (NFS/UNIX)

Two reasons, both of them pragmatic:

1. There are usually many fewer directories than there are files, so that
   strategies that would work for Directory IDs are likely to bog down
   sooner if used for files as well.

2. Currently, the only application which actually *depends* on Directory
   IDs is the Finder, and especially in conjunction with the Dekstop Database
   calls, this means that Directory IDs can be created on a per-session basis,
   as opposed to maintaining a (potentially very large) database on disk.

--
Amanda Walker
InterCon Systems Corporation

amanda@intercon.uu.net    |    ...!uunet!intercon!amanda