Subject: Re: [netatalk-admins] Problems with sherlock searching netatalk
From: a sun (asun@saul6.u.washington.edu)
Date: Wed Mar 17 1999 - 15:01:52 EST
I don't exactly understand this. Netatalk has always "pretended" to have
persistent DIDs. If I go do a "Find" and then click on an item, surely
the DID would have been persistent that long -- I haven't unmounted the
volume! What is this "underlying problem"? Is this the "incorrect
ordering of CNIDs that you're talking about?
i guess i should have been clearer here. if you turn on volume level
file numbers, the mac will use FPCreateID, FPResolveID, and
FPDeleteID. all these are AFP 2.1 features, so sherlock shouldn't
really need them to work. now, to get FPResolveID to work, you really
need a database. however, it turns out that when you do a find file
with Sherlock, it asks you to resolve an ID of 0. that's an illegal
value to use.
after some poking around, i did find out some information that seems
bizarre. it looks like sherlock is asking for information about the
root of the parent directory. as that doesn't really exist, i don't
think that's really allowed. i'll ask the powers that be what kind of
response sherlock might be expecting in such situations. it actually
exposed one of those "what do i do with this unexpected data" bugs in
netatalk.
That seems pretty odd. My guess would be that Sherlock creates an alias
record for each file that it finds, and stores a reference to that for
when the user clicks the item. Creating an alias should resolve for items
with macos 8.5, the alias manager knows how to deal with changing
dids. in any case, everything is fixed during a single session, so
that shouldn't make a difference anyway.
-a
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:27 EST