tonyrich@titanic.cs.wisc.edu (Anthony Rich) (03/08/91)
I recently dumped my entire hard disk onto a tape, reformatted the hard drive, then restored it from the tape in order to compact the hard disk. When I rebooted, I found to my dismay that Suitcase II had forgotten its list of DA's, fonts, etc. (except for the basic stuff in the System file, of course). The On Cue menu still had its list of applications and documents, but it had forgotten where they all were; the first time I select any one of them, On Cue says "I can't find <app name>. If you find it this time, I promise to remember where it is, OK?" It's particularly painful to set up Suitcase II again, since the resource files that used to be open are scattered all over various folders, and there's no "Find Resource" utility that finds the file that a particular resource lives in. It's hard to remember exactly which files used to be open and where they are. Suitcase II and On Cue use special setup files or resources to keep track of what they know, don't they? So why do they forget their stuff after a disk dump/restore? None of the *names* of the files or folders are changed by a dump/restore, only their physical positions on the hard disk. So what gives? -- ----------------------------------------------------------------------- | EMAIL: tonyrich@cs.wisc.edu | The essence of learning is | | Disclaimer: I speak only for myself. | repetition, repetition! | -----------------------------------------------------------------------
dburr@monsoon.Berkeley.EDU (Donald Burr) (03/08/91)
In article <1991Mar8.085219.13408@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: >I recently dumped my entire hard disk onto a tape, reformatted >the hard drive, then restored it from the tape in order to compact >the hard disk. When I rebooted, I found to my dismay that >Suitcase II had forgotten its list of DA's, fonts, etc. (except for >the basic stuff in the System file, of course). The On Cue menu >still had its list of applications and documents, but it had forgotten >where they all were; the first time I select any one of them, On Cue >says "I can't find <app name>. If you find it this time, I promise to >remember where it is, OK?" > >It's particularly painful to set up Suitcase II again, since the >resource files that used to be open are scattered all over various folders, >and there's no "Find Resource" utility that finds the file that a particular >resource lives in. It's hard to remember exactly which files used to be >open and where they are. > >Suitcase II and On Cue use special setup files or resources to >keep track of what they know, don't they? So why do they forget >their stuff after a disk dump/restore? None of the *names* of the files >or folders are changed by a dump/restore, only their physical positions >on the hard disk. So what gives? >-- >----------------------------------------------------------------------- >| EMAIL: tonyrich@cs.wisc.edu | The essence of learning is | >| Disclaimer: I speak only for myself. | repetition, repetition! | >----------------------------------------------------------------------- I think that Suitcase and On Cue use something akin to UNIX "inode" numbers to keep track of files. Basically, each file has something like an "allo- cation block" that contains directory information, et al, and this block is referenced by a number or a series of numbers. When you backup and/or restore your drive, those numbers change, even though your hard disk's name and the names of the files/folders in it don't change. Of course, this doesn't affect programs that find files based on pathnames, like White Knight (you don't have to reset your setting and procedure file locations in the Phone Book when you backup/restore). Note: I have NOT read Inside Mac or Tech Reference to Macintosh, or any such text, so take this "information" as a "speculation". Of course, if someone knows any better, please correct me... (Don't flame me though.. I'm just offering my *THEORY*) ______________________________________________________________________________ Donald Burr; Univ of California, Berkeley | America Online: DonaldBurr INTERNET: dburr@ocf.Berkeley.EDU |_CompuServe:_72540,3071____________ or: 72540.3071@compuserve.COM | "Send flames to /dev/null."
resnick@cogsci.uiuc.edu (Pete Resnick) (03/09/91)
The reason Suitcase forgets its files after a rebuild of the drive, as alluded to by another poster, is because Suitcase and other utilities use the DirID (directory ID) of the file to locate where it is on the disk. This is the Apple approved way of locating files. Unfortunately, these get re-created, and therefore renumbered when you rebuild a disk. They also fail to remain the same on certain Appleshare-like services, like CAP. I am currently in the process of writing a little INIT that stores the full pathnames for Suitcase files and adjusts the DirID's in the Suitcase Startup file to work properly (for my purposes, with CAP). If it turns out to be other than a hack, I promise to post it for others in just this situation. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
bdugan@teri.bio.uci.edu (Bill Dugan) (03/11/91)
Here's a tip for forcing Suitcase to remember pathnames that hopefully might help someone. On our Appleshare network, many Macs used the same suitcase on the server, with "Shared Suitcase" checked in Suitcase II. The problem was that if a volume is not present when Suitcase looks for it at boot, Suitcase "forgets" the suitcase forever. This happened very frequently when people would click "Cancel" on Appleshare's insanely-great-modal-dialog-box. Some technical individual would then have to use Suitcase to re-open the suitcase on the server. The fix was for the system administrator to set up the "Suitcase" init the way he wants it and then to use ResEdit to set the "Protected" bit on the "SCfl" resource in the Suitcase II init. This resource (there's only one SCfl) contains all the pathnames and so when the user clicks "Cancel", it tries to modify it but fails. No problem. You might encounter the problem we had if you swap external hard disks a lot and have suitcases open on various volumes that might or might not be connected at any given time. I can't imagine, however, that this hack/fix would work for the directory ID problem being discussed. bill