Excellent utility - jerroldleichter_dotmac

Being able to link to links can be valuable. Simple example: You have two versions of a program, both of which you want to keep around for some reason. You name the prog1 and prog2. For normal use, you create you create link prog that points to the most recent version, prog2. Later, when prog3 comes along, you move the link.

Now you want an alias for prog - or maybe some other user on your system wants an alias. A link from myProg to prog will track the most recent version.
But if adding a link goes to the underlying file, myProg is stuck at prog2 forever.

There are many other examples. Both forms are useful. I'm not familiar enough with what you can do in a contextual menu to know what's possible, but a good interface might be:

- If the selected file is not a symbolic link (or alias?), you only get
the single "make symbolic link" menu item;
- If the selected file is a symbolic link (or alias?) already, you get a
second "make symbolic link to xxx", where xxx is what the link
ultimately points to. Note that this also provides a facility that
you currently need to go to terminal and ls for: Finding out what
a symbolic link goes to.

An extension of the above is to follow the link step by step, with a menu item per step until you get to a non-link.

Alternative: Add an item to symbolic links "follow link", which opens Finder at the target of the link. Then you can easily follow where things go, and use the ordinary "Make Symbolic Link" exactly where you want.

Another useful addition: When a link is created, open Finder on the directory containing it, and select the newly-created link. This eliminates the whole discussion of "Where Did My Link Go?" in the Readme - and anything that shortens the docs is probably an improvement to the UI!

Reply to This

Saturday, September 17 2005 @ 04:54 AM PDT

Excellent utility - MacHound

Both of these are good ideas. I hesitate to make too many demands of freeware authors but I thought I ought to point out what seemed to be a shortcoming of Symbolic Linker, at least for me. One of my initial uses for Symbolic Linker was to make a batch of links from a folder full of media file aliases from content spread across my network. Symbolic Linker did this perfectly but, unfortunately, the unix program I was trying to use (wizd) got stuck where the links pointed to Mac aliases. As a result, I had to manually open each media folder (hundreds) and make symlinks one-by-one. I now have a better solution to my media file organizational problem so this isn't an issue for me anymore.

Sorry about all the multiple posts. VersionTracker was particularly slow that day and nothing seemed to be happening. I asked the moderators to remove my duplicate entries. (I'm not trying to skew the ratings!)

Reply to This

Sunday, September 18 2005 @ 02:54 AM PDT

Excellent utility - rcfa

I don't think the idea to link to the original rather than the link would be a positive change. One of the key differences of symlinks vs. aliases is that a symlink is supposed to point to a FIXED LOCATION and is supposed to break if nothing is at that location.
One of the problems of several apps is that e.g. in their preferences they do first resolve symlinks before storing a path, which is BAD behavior.

Example: You're running low on disk space, you create a link from /Users/myHomeDirectory/ to /Volumes/TempStorageVolume/myHomeDirectory/
You then buy a bigger hard drive, use ditto to move everything onto that drive, and all of a sudden things stop working. Why? Because a ton of preferences try to locate things at /Volumes/TempStorageVolume/myHomeDirectory/ instead of /Users/myHomeDirectory/
This is, because they did expand paths to files that contain symlinks, instead of storing the path as is and letting the symlink resolve at file access time.

While there are good things about aliases and bad things about aliases (that they are not transparently resolved by the file system), the key reason to have both aliases and symlinks is that they have different semantics, which depending on the usage scenario both can be useful in different cases.
So to try to sneak in alias behavior to symlinks through the back door (i.e. through the utility that makes the symlink) isn't a great idea IMO.

What would be a great thing, though, would be to have an option to do relative symlinks in addition to absolute ones.

e.g. you have a picture in your Pictures folder, and since it's relevant to some document you're working on, you make a symlink to somewhere in the Documents folder. So if the Document is in ~/Documents/Miller2005/ and the picture is in ~/Pictures/HolidayPictures/JohnMiller.12082005.jpg you can create symlinks within ~/Documents/Miller2005/ in two ways:
a) make a link to /Users/myHomeDirectory/Pictures/HolidayPictures/JohnMiller.12082005.jpg

b) make a link to ../../../Pictures/HolidayPictures/JohnMiller.12082005.jpg

The later has the advantage that if you e.g. backup your home directory by doing a ditto to another volume, the link will keep pointing to the same relative position. So if your main drive breaks and you try to access your backup, things will just work and not point to a location that no longer exists.
Similarly, if you're pointing to resources within a software development project, and you move the project folder, if you use relative symlinks, the resources if they are all in subfolders of the main project folder, will remain valid, regardless of where you move the project folder. If you use absolute symlinks, they will all break.

Reply to This

Saturday, October 08 2005 @ 09:50 PM PDT