Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Finder/Appleshare copying: ERROR #8053
Message-ID: <1991Apr10.001358.13337@nntp-server.caltech.edu>
Date: 10 Apr 91 00:13:58 GMT
References: <0704AC3C40C002C4@ctrvax.Vanderbilt.Edu>
Organization: California Institute of Technology, Pasadena
Lines: 46

EWINGRA@CTRVAX.VANDERBILT.EDU writes:

>I've been having problems for a long time regarding my GS accessing
>an Appleshare server.  I used to have a small Mac SE I was using as a server
>but lately I've been using my Mac IIfx running Personal Appleshare under
>System 7.0b5.  Regardless of the server, sometimes, completely unpredictably,
>the Finder will be unable to make the copy from server to either hard
>disk or RAM disk, saying "Unable to Complete Operation, Error #8053".
>Can Andy Nicholas or someone from the Finder team tell me what this error
>is, and if there is a workaround.  This thing is driving me CRAZY!!!!

This usually happens because the file's ProDOS filetype info hasn't been
properly set. We run AUFS on tybalt (AUFS is Appleshare Unix File Server) and
I had that problem because AUFS would _never_ set the ProDOS file type info,
only the Mac info. What is going on is that finder tries to copy a file whose
GS/OS filetype fields have reserved areas that aren't zero -- the ProDOS FST
returns an error $53 (parameter out of range) because those filetypes aren't
valid. Finder 1.3 just gives you a box and aborts instead of offering to
coerce the file info to be legal for ProDOS. (I have told Andy about this.)

The solution: a program that fetches files from remote directories and forces
their filetype info to be something legal (I used to use all zeros but now I
use BIN/$0). I recently modified it to change the Mac info to defeat AUFS'
automatic newline translation, so I could download binary files by holding
down option when it prints out the bogus file info and Mac info it pulls
from the AppleShare FST optionlist.

GG is an EXE that will also work if you finder icon map it (I have an icon
for any/any "*.dld" that is document with a blue arrow pointing down). I am
thinking of slapping a graphic interface and SFMultiGet on it and releasing
it, as a test case to make sure I understand this stuff (I want to put it
in LHG before LHG sees public release).

>Also, occasionally I run into a problem in which the Finder cannot properly
>make file and folder name translations when copying from an AFP server.
>Anyone seen this happen?

Yes. It shouldn't be random. Figure out what kinds of copies work and learn
to use them. I suspect that the new finder (when it comes out) will fix a lot
of that.

Todd Whitesel
toddpw @ tybalt.caltech.edu

P.S. GG is a 32K buffered version of FF ("FetchFile"), the original program
I wrote to teach myself GS/OS file access.