Date: Wed, 8 Jun 1994 13:52:38 +1000 From: "Michael.Smith" <Michael.Smith@maths.anu.edu.au> Subject: Tricks for keeping aliases connected Warning: I waffle on a bit in this message. This a brief account of my recent experiences with aliases. Hopefully it will be of use to others. A simple trick allowed me to do a backup-restore of my hard disk with only a few aliases ending up detached (some because I forgot to unlock them before starting, others because they ended up pointing across the new partitions). How do aliases work? -------------------- As far as I know, an alias encodes its destination in two ways. I won't go into too many details, since I have only educated guesses on precisely how it works, but experimentation can verify the following facts: (1) Stored within the alias is a "pointer" to the location of the target on the disk --- when a file is created it is assigned a unique pointer which remains unchanged as the file is moved around, renamed and modified. If the file is deleted, this pointer becomes invalid. If the pointer stored in the alias is valid then just follow the pointer to the target. (2) Also stored in the alias is the last known path to the file. For example the stored path might be "HD:Documents:targfile" which means that when the alias was last resolved it was to a file called "targfile" in folder "Documents" on hard drive "HD". So when the system attempts to resolve an alias it first checks whether step (1) gives the target, and only if that fails does it then check step (2). If both fail, the alias cannot be resolved. Bacause of step (1), you can create an alias to a file, and then move the file around, change the name of it and change the names of folders and drives that it is stored on. None of these operations changes the pointer to the file's information blocks. However, replacing a file by one with the same name does prevent step (1) from succeeding, but then step (2) comes to the rescue. Hassle free backup/restore -------------------------- What was I to do? I had a 330MB hard drive with a single partition named "Centris650", and I wished to back it up, reformat and partition it into 3 volumes, and then restore files into the 3 new partitions. First I ran an alias checking program, which searches disks for all aliases, and tries to resolve each of them (AliasBoss, AliasZoo and FileBuddy all do this for you). This ensured all my aliases on "Centris650" had both their components (pointer and path) updated. This was important since I may have moved some around a while ago without resolving them since, so their paths would be incorrect, and the whole trick it to rely on the path component of the alias. Then I backed up the disk into 2 different Stuffit archives, one for each of the intended volumes. After reformatting and partitioning the drive, I restored the files into the 3 new volumes named "part1", "part2", and "part3". But now every file was a new copy, and none of the pointers stored inside the aliases would point to their targets anymore. Moreover, an alias on one volume may now be for a file on another volume. All the paths stored in aliases start with the drive name "Centris650", so both resolving steps will(?) fail. In three steps practically all aliases are fixed. Rename "part1" to "Centris650", and run the alias checking program. It finds all the aliases on all the drives, finds that none of the pointers work, and starts looking at the last known pathnames. All the targets on the first partition can now be resolved, since the first partition now has the old drive name. In the process of successfully resolving by name, the pointers to files are updated as well, so when the name is changed back to "part1", all these fixed aliases remain valid. Repeat this step for "part2" and "part3". Ammendment: It is possible that renaming the volumes is not necessary, but I didn't pay close enough attention while I was going through this process to know for sure. A simple experiment seems to indicate that it is not necessary. Make a new folder called "XXX", and then an alias to it on the same volume. Delete the original. Rename the volume, and make a new folder named "XXX". The alias will find it, despite the fact the path is different. If the alias and the target are separated across partitions, the alias will not be fixed in this process. These must be fixed by hand (with the help of FileBuddy or something similar). End result --- backup and restore completed with a minimum of broken aliases. The only remaining problems are those file pointers that are stored in preferences files: eg your copy of Fetch or Anarchie can no longer find your "Download Folder", since when you set it the program stored the folder's pointer which no longer works bacause all files are new copies. Another mind numbingly simple tip --------------------------------- I like to keep aliases in readily accessible places, and original programs in well organised places :-). Typically I have 4 or 5 aliases to an important or frequently used program. Problem was, whenever I got an update to a program, there was a bit of bother replacing the old one by the new, because aliases usually broke. Now whenever I install a program, eg Fetch 2.1.2, I make sure that I store it in a folder that *does not* involve the version number. So I rename the folder to "Fetch folder", or something similar. I make sure the application does not involve the version number in its name, say "Fetch 2.1.2", since updates will then have different names. Rename it to simply "Fetch". Ignore the names of documentation files (indeed, hopefully they will be named "Fetch 2.1.2 docs" or something similar). Now I make all the aliases I want of the application. When I get a copy of Fetch 3.0, updating is now easy. Rename the folder it is in to "Fetch folder", and make sure the application is called simply "Fetch". Replace the old folder by the new one. All aliases will continue working. Cheers, Michael. ---------------------------------/|-|--|-|--|--Michael-Smith------------------- Michael.Smith@maths.anu.edu.au /-| |\ | | | Mathematics (CMA) -------------------------------/--|-|-\|-|_/|--Australian-National-University-- http://pell.anu.edu.au/~smith/Michael_Smith.html