🚀 go-pugleaf

In article <1982126@mtsg.ubc.ca> Les_Ferch@MTSG.UBC.CA writes:

> Today I tried accessing our Appleshare server (a Sun running CAP)
> from a IIgs running System Software 5.02. I was able to mount the
> server volume, copy files to the server, and erase files from the
> server, but I could not copy files from the server.

> The message GSOS presented in a dialog when I tried to copy a file
> from the server to the GS' hard disk or ram disk was:

				   System Error.
		 #8053    Can't complete this operation.

This is an "invalid parameter" error that is occurring on a _CREATE call.

> Does anynone know what is going wrong, and better yet, what the
> solution is?

There is a problem somewhere (not sure if it's on the IIgs appleshare
file/auxtype translation side or on the CAP side.  Presumably it has to be
CAP since real AppleShare servers don't have this problem) such that files
are getting bogus file & auxtypes.  In particular, if you take the name of
a file to be a pascal string (e.g. "foobar" = "\006foobar"), then the
filetype is the length byte, and the auxtype is taken from the 2nd character
on.  (From my example, you'd get the file "foobar" as filetype 06, auxtype
61626f6f)  It looks like a misplaced buffer or something like that.  Since
the upper word of the auxtype is nonzero, you get an invalid parameter error.
This problem doesn't affect directories.  What I find strange is that those
same files are correctly typed when viewed from a Macintosh, so there is some
strange combination of the CAP software with the IIgs AppleShare type
translation going on.

Anyone at Apple have an insight on this one?


Scott Lindsey     | I dig iguana in their outer space duds
Claris Corp.      |    saying, "Aren't you glad we only eat bugs?"
ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple,
wombat@claris.com |    StyleWare, the author, or anyone else living or Dead.