|
| KON |
It's you again. |
| BAL |
It seems our bid for drumming up Puzzle Page authors hasn't gone well. |
| KON |
I guess everyone's waiting for the Mac OS 8 release. From what I hear,
they'll be waiting quite a while. |
| BAL |
I've got a lot of work to do. Can we get on with this? |
| KON |
OK. Have you ever heard of Retrospect Remote? |
| BAL |
Yeah, we run it. It's that backup program. It slows your machine to a
crawl when it's doing its thing, but we've never had a problem with it. Our
engineers don't allow it on their machines, though. |
| | KON |
Apparently someone went around one morning and installed it while we were
all sleeping. It's been running great for the last year, but suddenly one of
the machines started showing an execution error. |
| BAL |
Easy enough. Go check out the logs and see what it's complaining about.
|
| 100 | KON |
It says folders are nested too deep on that machine. Sure enough, the
machine has a folder called "<unknown name>," and inside that folder is
another called "<unknown name>," and so on. It was mixed in with our
project files. |
| BAL |
What system are you running? |
| KON |
A Power Mac 7100/66 with 32 MB of RAM and an 800 MB hard disk, running
system version 7.1.2 -- the "last trusted system," according to Chris
Derossi. |
| BAL |
What happens when you use the Finder to get info on the folder? |
| 90 | KON |
It says there are 99 items inside this one for zero K of disk space. |
| BAL |
Go in a level and try the same thing. Still 99 items? |
| KON |
Yep. |
| BAL |
Go in a few more levels and rename one of the folders. Come back out and
go back in. Anything unusual? |
| KON |
Nope. The renamed folder kept its new name. The Finder tells you there are
99 items inside it. |
| BAL |
Just keep opening folders. How deep does it go? |
| 80 | KON |
After opening folders for a few minutes, you get too bored to
continue. |
| BAL |
Rename every tenth folder or so, to create some landmarks. Dig down doing
this. Can you Command-click on the window title and see the whole hierarchy? |
| KON |
Yes. You're doing one heck of a test on the pop-up menu manager. |
| BAL |
So, what happens? |
| 70 | KON |
After you do this about 150 times, the Finder displays the familiar "out
of memory" message. It says you might try closing some windows to make more
memory available. I have the feeling this might be one case where that advice
actually works! |
| BAL |
Do a Get Info on the hard drive. How many items does it have? |
| KON |
16,774 items on disk. |
| BAL |
Somehow I was expecting a larger number! Try copying the folder. |
| KON |
We crash. |
| BAL |
Where? Any clues? |
| KON |
In CopyDoubler. |
| BAL |
That sounds like a subject for another column. Hold down the Control key
when copying the folder to tell CopyDoubler to stay out of it. |
| 60 | KON |
The Finder puts up the copy dialog, waits about two minutes, advances
the thermometer the entire way in about three seconds, and then waits another
two minutes before finishing. The copy dialog says there are 100 items to be
copied. You now have two folder hierarchies. |
| BAL |
That's interesting. I've seen the Finder copy way more than 100 items at
one time, but somehow its knowledge of folder nesting is limited to 99 or 100.
Do a Get Info on the drive again and see how many new items were created. |
| KON |
Now there are 18,679 items on disk -- 1,905 new ones. |
| BAL |
Copy it to a file server. |
| 55 | KON |
OK. Now the Finder does the copy the same as before, except after the
thermometer is finished, the dialog stays up, waiting for a long time. |
| BAL |
How long? |
| KON |
Suppose we go to a long dinner at the Peppermill Lounge. When we come back
it still won't be done. |
| BAL |
Look at the folder hierarchy on the network from another Mac. |
| KON |
While it's still copying? |
| BAL |
Sure. |
| 50 | KON |
You see a bunch of folders, as you'd expect, except the network is
really slow. Apparently the Finder is generating a lot of network traffic
trying to create all those directories. |
| BAL |
Stop that file copy. |
| 45 | KON |
The Stop button in the copy dialog is highlighted (indicating that you
pressed it), and the network is back to normal, but the copy dialog doesn't go
away. |
| BAL |
Reboot and look at the folders in Standard File. |
| KON |
No new clues. How deep do you want do go? |
| BAL |
Hmm. Try running Norton Utilities on the disk. |
| KON |
There were a few bundle bits that are wrong. But once those are fixed,
Norton says the disk is fine. |
| BAL |
Try DropStuffing the folder. |
| KON |
DropStuff crashes. |
| BAL |
Try Disk First Aid. |
| 40 | KON |
It tells you that the folder nesting exceeds the Finder-recommended
nesting of 100. But other than that, it says the disk is fine. |
| BAL |
I guess those folders are really there. The system is running into a bunch
of boundary conditions trying to deal with them. The question is how they got
there, and I'm not sure how we figure that out given that all we have is a
smoking gun. |
| KON |
Wait a second...the column isn't supposed to end this way! |
| BAL |
OK. I've got an idea. I'll try looking at these folders from MPW with a
files -r -c command. |
>
| 35 | KON |
MPW prints out a bunch of folders and then crashes. The interesting
thing is that it crashed right after printing out the 100th level down, which
we know from the "rename every tenth folder" exercise we did earlier. |
| BAL |
Well, there are some mysteries that we should be able to solve. Clearly,
some software on this machine created the folder called "<unknown name>,"
probably when a directory with a null name or some other exception condition
was encountered. |
| KON |
OK. |
| BAL |
It's probably the Finder, the File Manager, or one of the applications
that's commonly used on the machine. Let's ask Paul Mercer if he knows anything
about it. |
| 30 | Paul |
First of all, the Finder isn't going to rename a folder on you. And
second, even if it did, no one on the Finder team would give the folder a name
that contains an angle bracket -- that's just too unpleasant aesthetically.
Maybe the File Manager would do such a thing, though. |
| KON |
We could try Dave Feldman. I'm not sure he'd have the same issues with
angle brackets that Paul has. |
| 25 | Dave |
No issue with angle brackets here! But the File Manager doesn't ever
attempt to detect or fix damaged catalog info. It will rebuild the volume
bitmap (that long pause when remounting a disk after a system crash), but it
leaves everything else alone. No matter how much it's abused by the Finder, the
File Manager will never surreptitiously set a folder to "<unknown name>."
Tell Paul I said what does he know, he's been gone from Apple long enough to
have forgotten what little he once knew about the File Manager. Furthermore,
the File Manager doesn't care how deep you nest folders; that's a Finder
problem. |
| BAL |
Well, the system hasn't changed much since either of those guys left
Apple, so it's probably something else. Maybe you can get someone at Apple to
search all the system sources and see if they can come up with a hit on
"unknown name." |
| 20 | KON |
I talked to Jim Luther about it and he said it shows up in only one
place -- the Alias Manager. Apparently the Alias Manager will store the name of
the user who created the alias as part of the alias record. If a user who logs
on as a guest creates an alias, the name of the alias creator is set to
"unknown name," but there are no angle brackets. |
| BAL |
Let's grep the hard disk and see if we can find any hits on "<unknown
name>." |
| KON |
How do you propose we do that? |
| BAL |
Have you seen AltaVista? |
| KON |
You mean the search engine on the Internet? Totally awesome. When you do a
query they can instantly give you a list of the top hits from any Web site. But
what does that have to do with this puzzle? |
| BAL |
Well, I figure they can search huge amounts of data way faster than we
could ever do it on our local machine. So we dump the entire contents of the
hard disk to a Web page, register it with AltaVista, and perform the search. |
| KON |
A little unrealistic, but not a bad idea. |
| BAL |
Ron Avitzur thought it up. |
| KON |
For those keeping score, you're approaching 15. |
| BAL |
OK, OK. I'll use Norton Disk Editor and search the whole volume for the
string "<unknown name>." |
| 15 | KON |
The first hit is in the catalog. I get the feeling you're going to find
at least 1905 of these on this disk, probably more since you duplicated the
folders so many times. |
| BAL |
OK. Try it on one of your other development machines. |
| 10 | KON |
The string is found in a bunch of places but the sectors aren't owned by
a file. But then the needle in the haystack pokes your probing finger -- you
find the string in the MPW Shell application. |
| BAL |
Open up MPW Shell with ResEdit and find out which resource it's in. |
| KON |
Duh! Wrong tool for the job! ResEdit can't search the entire resource
fork. |
| BAL |
OK. Use Resorcerer. |
| KON |
You find the string in CODE resource 27, called %A5Init. |
| BAL |
So, it sounds like we should contact someone in MPW land and see if they
know what's going on. Here's Alex McKale; maybe he can help us. |
| 5 | Alex |
Sure enough, Projector will create folders with the name "<unknown
name>." CheckOutDir creates a folder hierarchy that matches the project
hierarchy. |
| BAL |
The project hierarchy on this machine is only three or four levels deep,
not 1905! Any explanation for that? |
| Alex |
Did the machine ever crash while checking out? Maybe some script got in
an infinite loop, and you hit the reset button or crashed after some time. This
would mean the depth of the hierarchy is based on how long the machine was
running in the loop, rather than on some magic number, such as everyone's
favorite year plus 1. |
| KON |
It happened on Richard's machine. He says his Mac crashes all the time,
and he'd be hard pressed to tell you what it was doing during any particular
crash. |
| BAL |
Hmm. I guess we just need a plausible explanation. Any ideas, Alex? |
| Alex |
Your guess is as good as mine. CheckOutDir does very little error
checking, so if the project tree got munged -- for example, if there was no
terminator in the project folder hierarchy -- it would keep creating folders
called "<unknown name>" until it hit a terminator. Give me a reproducible
case, and this thing is dead meat. |
| KON |
No can do. I guess the exact cause will remain a mystery, along with the
true nature of consciousness, the details of Jimmy Hoffa's demise, and the
location of my other red sock. Well, at least we managed to narrow it down to
Projector, so we can point both our accusatory fingers in the same direction.
If nothing else, maybe this will get the Projector folks to add a little more
error checking to CheckOutDir. |
| BAL |
Nasty. |
| KON |
Yeah. |
