[206] in installers
Re: Mac Eudora 3.0.2 installer creator/type wrong
daemon@ATHENA.MIT.EDU (Marshall Vale)
Wed Dec 9 13:55:29 1998
Resent-From: <mjv@MIT.EDU>
In-Reply-To: <199812082140.QAA22957@helpdesk3.mit.edu>
Date: Wed, 9 Dec 1998 13:51:54 -0500
To: Brian D Fisher <panda@MIT.EDU>
From: Marshall Vale <mjv@MIT.EDU>
Cc: installers@MIT.EDU, helpsuper@MIT.EDU
Hi Brian,
> I had a client attempt to install Eudora today (log 128050), but when he
> double clicks on the installer icon, it says "The document "MIT Eudora 3.0.2
> Installer" could not be opened, because the application "Stuffit"
> could not be
> found. Could not find a translation extension with appropriate translators."
> Since it did not work for the client after downloading the file 5 times, I
> decided to try it on the Mac here, and I got the same error message.
> Hopefully you can fix this problem soon.
While it may look like the archive on net-dist is corrupt, this is
actually a really sticky bug/condition relating to the Mac OS 8
Finder. The short of it is that the Finder is stomping on the file
type and creator code associated with the file. Here's what's going
on...
Applications like Stuffit Expander and various installers create
files initially with a different file type and creator code than the
eventually end up with. That is, when Expander is done expanding a
file, it writes the file's real file type and creator code over the
temporary ones (in Expander's case, a Stuffit part type).
When the Finder notices a new file has been created, it reads in the
file's type/creator codes to check against the Desktop Database. For
files that are still busy (like expanding), the Finder tries to clean
up its trail and writes the type/creator code back to the file. The
screw case that you were seeing happens with the file
expansion/download/install etc, is so fast that it finishes before
the Finder writes back the temporary type/creator. Thus, the Finder
trashes the final type/creator code with the original temporary ones.
Sort of a nasty race condition basically.
How to solve this? One way is to use a type/creator code editor such
as FileTyper (shareware on info-mac), MoreFiles CMM(shareware) or
ResEdit to edit the file type back to what it should be. If the file
is an installer as in this log's case, using a type of 'APPL' and
creator of '????' will work.
If it doesn't look like you can have the user edit the type/creator
fields, you can try having the user download or expand the file from
a slower link or to a slower disk, something like a floppy or Zip
probably ought to do it.
Apple has taken some steps to improving the situation in Mac OS 8.5
where it may still possibly happen but should happen less. The
permanent solution introduced in 8.5 involves the tools vendors
changing their software and that always takes time.
Hope this helps and let me know if you have any other questions about
this situation.
Marshall
Marshall Vale | mjv@mit.edu | Information Systems | "Knusprig
Lead Mac Dev/Analyst | Massachusetts Institute of Technology | und Lecker"
