> but as soon as I put my data back on it broke again. And no, X-Master > doesn't seem to be the problem, because I deleted it to see.
Hmm. I was having *exactly* that problem, and it turned out to be that I'd restored an old BigClock database (AlarmList.pdb) but the current BigClock barfs on it [ie. wedges on next paperclip-reset.] It took probably 5 or 6 hours of divide-and-conquer to find it (I have about 6M of normal software on here, plus 2M of maps, though it looks like junglesoft killed off this map program so I need to find a replacement...) In retrospect it might have been faster to debug this under POSE, since I wouldn't have had the hotsync delay... I wonder if something like x-master or hackmaster could actually do this kind of tracing; there *is* enough context to do that kind of back trace, I'm pretty sure... > Short of going through every database one by one, is there any way to CS 101 lesson: divide and conquer. Don't do one-by-one, load *half* of them, and then reset, and then see if it fails. (Actually, I loaded all of the pdb's and then half of the prc's -- since prc's are the only actual *code* but then had to play some games to figure out that the program that was crashing was losing on a bad datbase...) Now you've fairly rapidly either found that they're in this half, or that they're in the other half; either restart and split this set, or continue and load half of the remainder. 100 apps then take 7 iterations... _______________________________________________ Pilot-unix mailing list [EMAIL PROTECTED] http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
