dan@uwmacc.UUCP (dan jatnieks) (11/15/86)
Background: Mac Plus, HD20, Kermit 0.834, latest system everything.
Here's the scoop. I recently used FTP to get a file from Sumex called
'MACINTOUCH-BENCHMARKS-861028.HQX' and proceeded to try to transfer that
file to my macintosh using Kermit (version 0.834). Well it just so
happens that Kermit on the mac really doesn't like that filename because
just as the transfer starts, up pops a dialogue that says "ZCHKI failed: -37".
Oh great, so I click on "OK" and it pops up again. So I click "OK" and
it pops up again. And again. And again. Rebooting was the only alternative
I had at that point (as far as I know).
[ Later I successfully transfered the file by changing the name to
"MACINTOUCH-BENCHMARKS.HQX", so it seems that it was indeed the name
that was the problem. Whether it was the "861028" or that it was too
long or something else I have not checked.]
That's the first part of the problem. The second part is that that
problem file was only one in a group that I was transfering using the
wildcard "kermit s *.hqx" on the Unix machine that I was transfering
from. So before the "hang-up" occured, there had already been about 700K
in 10 files transfered. When I reboot the mac, there is indeed 700k less
space on my HD20, but none of the files that transfered show up at all.
I assume Kermit doesn't finish closing them until the entire transfer
is complete or some such thing.
Well, being optomistic (and on a direct line 9600 baud) I tried the
whole thing again. Exit 700K more of my HD20 space when the exact same
thing happens. Super, huh?
O.k. so I eventually figured out how to avoid the problem in this case
(by changing the offending file's name). My real problem now is to find
a decent way of recovering the lost disk space short of re-init'ing the
HD20. That is where I am stuck... Anyone with bright ideas (or even
shots in the dark) please let me know. I already had 18Mb used up on
the disk, and could really use that 1.4Mb for something other than a
Kermit dump.
danj.tim@hoptoad.uucp (Tim Maroney) (11/16/86)
I don't have a solution, but I do have a bit more information. Last Spring,
when I was writing a database engine in Consulair C (gag) on an HD20, I had
the same problem. When test runs would crash the system, frequently the
database file would be zero length (since caching was on), but its space on
the disk would still be taken up. Not by any file, it would just be gone.
Since my test files ran into hundreds of K, this was a serious problem. I
had to back up my disk over TOPS to an AST 4000, reformat the HD20, and then
restore the backed-up files, at least three times. So, this is clearly not
a Kermit problem.
I don't know whether the question was with (1) the HD20 (2) HFS or (3)
caching. I never did get around to calling Tech Support for some reason.
Try looking at the munged file with the new Fedit and see if that tells you
anything - the old Fedit didn't understand HFS, so it wasn't much use.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)dgold@apple.UUCP (David Goldsmith) (11/17/86)
In article <511@uwmacc.UUCP> dan@uwmacc.UUCP (dan jatnieks) writes: >... > O.k. so I eventually figured out how to avoid the problem in this case >(by changing the offending file's name). My real problem now is to find >a decent way of recovering the lost disk space short of re-init'ing the >HD20. That is where I am stuck... Anyone with bright ideas (or even >shots in the dark) please let me know. I already had 18Mb used up on >the disk, and could really use that 1.4Mb for something other than a >Kermit dump. There are two new utilities from Apple which come with the new Hard Disk 20 SC. You should be able to get these utilities from your authorized Apple dealer. One is Disk First Aid, a utility which will repair some problems with HFS volumes, among them loss of free space. The other is a desk accessory called Find File for searching an HFS volume for files whose names match a given word. If your dealer doesn't know where to find these utilities, tell him they are on AppleLink in the News icon, in the Software Updates folder. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY
werner@ut-ngp.UUCP (Werner Uhrig) (11/18/86)
> One is Disk First Aid, a utility which will repair some problems with > HFS volumes, among them loss of free space. well, I have no complaints about the program 'working', however, I must say that it is very cryptic about what it is doing. When I ran it against my DataFrame that could not be backed up successfully by a LoDown tape-drive, Disk First Aid reported that "something is wrong - do you want me to fix it?" I took a deep breath and said YES (shaking in my boots about losing my data to this unspecified action) - "done" it reported in a fraction of a second and I have had no problems since. Now, it wouldn't have been that difficult to have the program report the nature of the problem and the nature of the repair it was proposing to perform, because, quite honestly, wouldn't you have made fun of me if I had had to report that something unspeakable had happened after I said YES ...? (I would have lectured YOU in the reverse case about letting "strange" programs do "undefined" things to your hard disk - right after I would have stopped laughing about the foolishness) Now, sure, even if the program had provided the information, this would have meant little protection against things not working out, but, at least, you'd have an inkling on where to poke around with your debugging software ... And before anyone draws an analogy about "asking your doctor about the details of an operation" .... yes, I ask, and, besides, my lawyer will be happy to sue over malpractice by the doctor but less than thrilled to hear about what a program did to my hard-disk ....if that could be established at all in the first place.
jimb@amdcad.UUCP (Jim Budler) (11/20/86)
In article <511@uwmacc.UUCP> dan@uwmacc.UUCP (dan jatnieks) writes: > That's the first part of the problem. The second part is that that >problem file was only one in a group that I was transfering using the >wildcard "kermit s *.hqx" on the Unix machine that I was transfering >from. So before the "hang-up" occured, there had already been about 700K >in 10 files transfered. When I reboot the mac, there is indeed 700k less >space on my HD20, but none of the files that transfered show up at all. >I assume Kermit doesn't finish closing them until the entire transfer >is complete or some such thing. I have encountered this problem with other terminal emulators, which I assume do not issue a fflush(), just a close() on the files. On the mac, this may leave the in memory disk directory in disagreement with the on disk directory. Result, any crash before a fflush() is issued may leave the disk directory at it's original state, but may have allocated allocation blocks. A workaround: command-shift-1 or 2 the disk between file transfers to force such a flush. -- Jim Budler Advanced Micro Devices, Inc. Logic CAD (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4}!amdcad!jimb Compuserve: 72415,1200 Witty saying: "What's up, Doc?" - Bugs Bunny Disclaimer: (AMD is || I am) not responsible for anything I say.