KON & BAL'S PUZZLE PAGE: Folder Fun
Konstantin Othmer and Bruce Leak
See if you can solve this programming puzzle, presented in the form of a dialog between Konstantin Othmer (KON) and Bruce Leak (BAL). The dialog gives clues to help you. Keep guessing until you're done; your score is the number to the left of the clue that gave you the correct answer. Even if you never run into the particular problems being solved here, you'll learn some valuable debugging techniques that will help you solve your own programming conundrums. And you'll also learn interesting Macintosh trivia.
>
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. |
SCORING
70-100 | Congratulations! You win free lifetime upgrades to MPW. |
45-60 | You win a free copy of Mac OS 8. |
25-40 | You win a lifetime subscription to eWorld. |
5-20 | You win a dinner with Paul and Dave. |
KONSTANTIN OTHMER AND BRUCE LEAK are cashing in on the enormous popularity of the Puzzle Page by starting their own online magazine. After rejecting titles like MacsBug Life and Dead Mackerel, they've settled on Mired as the name for their daily diary of debugging. The first issue will include hard-hitting articles like "MacsBug: The Best Command-Line Interface for the Mac?" and "Celebrity dcmds." Watch for it soon in your local cybernews shop!*
Thanks to Chris Derossi, Dave Feldman, Jim Luther, Alex McKale, and Paul Mercer for reviewing this column.*
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine