EWINGRA@CTRVAX.VANDERBILT.EDU (04/10/91)
'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!!!! 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? -Rick Ewing Vanderbilt University
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/10/91)
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.
shrinkit@Apple.COM (Andrew Nicholas) (04/10/91)
In article <0704AC3C40C002C4@ctrvax.Vanderbilt.Edu> 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". If the finder ever says anything like that, it's safe to look at the low byte and translate it into a GS/OS error code. In this case it's $53, parameter range out of error. "But how could I be getting that?" you say. Every once in a while AppleShare seems to give back bogus auxtypes with the high word of the auxtype set to $FFFF (in fact, the whole auxtype is $FFFFFFFF). And, because you're trying to drag something from the AFP volume to the ProDOS volume, the ProDOS FST has to OK the parameters sent either in the create or setfileinfo calls (you could OSBRK using GSbug on either to figure out if this really was the case, but it probably is). If you do a _SetFileInfoGS using the exerciser on the AppleShare volume (on the particular file of course), setting the value to something that the ProDOS FST understands (ie, less than $10000), the error will stop showing up. Seeing as how this just also happened to Jim Merritt today also, I'll have to go talk to one of our network gurus and see what's up. andy -- Andy Nicholas GEnie & America-Online: shrinkit Apple IIGS System Software CompuServe: 70771,2615 Apple Computer, Inc. InterNET: shrinkit@apple.com
EWINGRA@CTRVAX.VANDERBILT.EDU (04/11/91)
To Andy, You're right. The AUXtype does appear to be the problem, as I brought up a standard file info program, changed to auxtype from FFFF to 0000, and then I could copy the file. Hmmmmm. Well, now that we seem to know what the problem is, what can be done about it? Is it possibly to enact a fix (to System 7.0FC1) before the next final candidate hits? (And we know that there will be another one ;-). It kinda sucks to have to do this everytime this error comes up. But at least I can do something about it. Thanks, dude. -Rick Ewing Vanderbilt University
EWINGRA@CTRVAX.VANDERBILT.EDU (04/13/91)
Well, Todd, I for one would love to have this program (GG) in any form, but if you care to put a real interface on it and then ship it, then that's ok too. I can manually fix my problems now, but it would be nice to have something that does it for you. --Rick Ewing ewingra@ctrvax.vanderbilt.edu Vanderbilt University