A couple of nice folks responded privately, one of whom very
generously allowed me to call him voice to hash things over, and
then stuck with me via email as I wrestled with the problem, even
putting up a fresh copy of the Yarn 0.79 archive for me; I was
getting to the point of desperation and was thinking of wiping
out the whole works and starting over again.
Turns out I won't need to use it.
I just figured it out this morning. Yarn creates a temporary
working subdirectory called REPLIES while it's running, which it
then removes when you exit the program. I hadn't known that.
The subdirectory is included in the Files list in the
documentation, but it isn't identified as being temporary and is
listed along with the permanent Yarn subdirectories.
I had assumed, since Yarn had never created a REPLIES
subdirectory (that I had seen), this was a mistake in the
documentation, something left over from an earlier version that
hadn't been edited out for 0.79.
But I'd tried everything I could think of, and so I figured I'd
create a REPLIES subdirectory and see what happened, even though
Yarn had been running just fine without one all along (or so I
thought).
Lo and behold, DOS balked. Wouldn't create the subdirectory. (I
believe "Access denied" was its helpful and informative
response.)
But then light dawned.
I looked in the main Yarn directory, and sure enough, there was a
(text) file called REPLIES, dating from right before Yarn had
stopped being able to open/create reply packets.
How it got there is another mystery, which I won't go into. But
all I had to do was rename that file, and Yarn is again working
perfectly.
It occurs to me that this is something that should be in the
troubleshooting section of the documentation for any program that
creates temporary subdirectories while it's running: if the
program doesn't work properly, check to make sure there isn't a
file in the main directory with the same name as one of the
temporary subdirectories.
Or, alternatively, the programmer should give the temporary
subdirectories very esoteric names--some programs give temporary
*files* names consisting of random character strings that are
different each time the program runs; why can't this be done with
temporary subdirectories as well?
Given what Yarn is for, the likelihood of someone happily
creating a text file called REPLIES in the main Yarn directory is
fairly substantial, I would imagine. That ain't how mine got
there, as it happens, but it could very easily have been.
It should also be one of the first questions one asks someone
who's having a peculiar problem with a program. I've NEVER seen
or heard it asked, anywhere, any time, about any problem, even of
rank newbies to computing. Seems to me it should be part of the
standard trouble-shooting routine, near the top of the list of
things you want to rule out.
A program also ought to be able to generate an error message
identifying this specific problem should it occur. "UNPACK
FAILED: C:\COMMO\OUT\CNCT.REP" didn't exactly do it for me, since
it pointed *away* from the location of the problem. "UNPACK
FAILED: CAN'T CREATE TEMPORARY DIRECTORY C:\JUDY\REPLIES" would
have been sufficiently informative to have added at least a
24-hour day to my life (the amount of time I have ended up
spending trying to fix this).
JUDY'S GLITCH LAW: The longer you work on a problem, the more
things you try without success, the more esoteric the
possibilities you find yourself entertaining, and the more the
results you get appear to be contradictory, the more likely it
becomes that you overlooked something very simple.
COROLLARY TO JUDY'S GLITCH LAW: It's probably something
involving a basic DOS operation. (Good luck, Windows users!)
(I'm sure this isn't original with me, but I've never seen it
explicitly stated anywhere. Usually what you hear is more like,
Once you've eliminated all the probable explanations, what
remains has to be the correct one, no matter how improbable.
Which may lead you in exactly the wrong direction.)
Many thanks to the two gentlemen who offered suggestions; they
helped me focus in on the nature of the problem instead of
floundering all over the place.
Whew.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Judy Stein * The Author's Friend * jstein@cnct.com +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++