On Sat, 27 Nov 2004 20:31:45, Laurence Harris <email@hidden> wrote:
> On 11/27/04 3:30 PM, Mike Kluev didst favor us with:
>
>> On Fri, 26 Nov 2004 22:44:25, Laurence Harris <email@hidden> wrote:
>>
>>> On 11/26/04 5:18 AM, Mike Kluev didst favor us with:
>>>
>>>> FWIW, FSRefs *could* have been implemented to represent non existing
>>>> items, being 80 bytes (as they are now) or even smaller. How? If item
>>>> name fits into FSRef, the case is solved. If item name doesn't fit,
>>>> FSRef could store the reference to the auxiliary data where the name
>>>> is stored. Similar to the way FSRefs (or just dirIDs) are implemented
>>>> on UFS (there are no real dirIDs on UFS, so all those parIDs/dirIDs/
>>>> fileIDs are synthesized and nodeID->path mappings are stored in some
>>>> auxiliary table).
>>>
>>> The system doesn't need to store names which might never be used.
>>
>> Quite the opposite happens on UFS where the system does need to
>> store names which *might* be used (even if they will never used).
>> Just think what happens when you call FSGetCatalogInfoBulk on UFS
>> folder: all those returned FSRefs do not have enough space to store
>> long names, and those names must be available somewhere, because
>> they *might* be used.
>
> I don't understand. Every entry in the file system has a name whether you
> get an FSRef to that item using FSGetCatalogInfoBulk or not.
Yes, but I was talking about auxiliary in memory data. What I was
saying is that the moment you get an FSRef for some UFS file/folder
with long name, some auxiliary data in some system table must be
created and maintained by the system (until your app quits I believe).
What exactly this auxiliary data contains on UFS is implementation
detail, but at least it must contain the file name, because there
is no other way to reference files on UFS (on HFS+ there are
nodeIDs built-in hence there is no need for auxiliary data).
>> UFS just doesn't have the opportunity to
>> store less information to reference file than its name.
>
> I don't understand your point. At least, I don't understand how any of this
> relates to my statement that the file system shouldn't allocate space to
> store names for files that may not ever be created.
Earlier you said "which might never be used", and my example was about
using, not creating. Anyway, my point is: if the system needs to
allocate some extra memory to be able to represent FSRef of existing
file (this happens on UFS), then it is not that bad for the system
to allocate some extra memory to be able to represent FSRef of non
existent file. [Besides, there is the whole other opportunity about
which I wrote in the other thread "Deprecated Systems": to have two
kinds of refs.]
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
