Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!haven!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Finder Get Info comments
Keywords: Get Info, Finder, System 7
Message-ID: <1990Nov24.220113.17104@eng.umd.edu>
Date: 24 Nov 90 22:01:13 GMT
References: <258@karp.albany.edu> <21814@well.sf.ca.us>
Sender: news@eng.umd.edu (The News System)
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 25

In article <21814@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes:
>I would be very surprised if the finder implemented the locking protocol
>necessary to insure simultaneous update access to the desktop database.
>Your best bet would be to see what appleEvents the Finder accepts, (documented
>in Inside Mac Vol 6) and if there are not appleEvents to get and put the
>finder info, petitioning Apple to add them pronto. Inside Mac Vol 6 may be
>available from APDA, and all registered developers got a copy on the Big Bang
>and Beta Bang System 7 CD-ROMs.

Huh?  The Finder calls the desktop manager routines documented (incorrectly)
in Inside Mac Volume 6.  If an application used the same routines, why
would there be a problem?

>If you just write into the file while the Finder has it open, you will
>make the structure the Finder has cached about the file into garbage, and
>it will garbage the file the next time it writes.
The caching is done by the Desktop Manager itself, not the Finder, or so it
appears from a little MacsBugging in Finder 6.07 with Desktop Manager 
running-- the finder caches the icon, etc, but the cache seems to be
invalidated on context switches anyway.  And this caching won't damage the
file, though I guess it is possible that it would wipe out your added comments.

--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
     .sig under construction, like the rest of this campus.