On 13/12/2002 at 08:29 +0000, Jon Reades wrote:
On 13/12/2002 at 07:06 +0000, Dave Cross wrote:
I assume that by "alias" he means some kind of symbolic link. I've
An alias doesn't really map neatly to either a symbolic nor a hard link in Unix terms, although it has elements of both. Tedious detail follows. [This is your hint to skip this.]Yes, an alias is *effectively* a symbolic link (I believe that there are some differences under the hood, but that's probably because of the HFS/HFS+ file system).
An alias contains a whole heap of information about where to find a file, including what volume it was on, its creation date, and its location (both as the equivalent of an inode and the full path). (The curious can find quite a lot about the Alias Manager at developer.apple.com simply by searching for 'alias'.)
It's not necessary for an alias to be created on an HFS or HFS+ file system. Next time I've booted OS X I might try creating a UFS disk image to test this. You can certainly leave aliases on remotely mounted file systems.
Like a hard link, aliases continue to be resolved even if the file is moved around (although only if it's moved around the volume it was created on, usually). Unlike a hard link, and like a soft/symbolic link [0], the alias is definitely not the same file; deleting the alias and deleting the file it references do very different things (one leaves a dangling alias that can be retargeted, the other leaves the file untouched and simply removes the alias).
Annoyingly, the Mac OS X Finder can resolve symbolic links, but cannot create them, whereas the CLI utilities can neither create nor resolve aliases This is shame, since to my eyes this is another example of where the Unix model is exhibiting 'worse is better' behaviour.
Returning to the original question, a file being unpacked as an alias, especially from a 'foreign' platform, is fairly unlikely. However, and I'm not able to test this situation (today), it's possible that:
* Mac OS 9.2 has been updated to understand symlinks
* The latest versions of Stuffit (or whatever tool was used) understands
that a symlink in a tarball should be expanded as a symlink
* A tarball has been created which used a symlink rather than resolving
it to the target file
In that case, the Finder may present what looks like an alias but is in fact a symlink from a foreign system which, unsurprisingly, fails to resolve. Get Info (command+I) on the alias may show whether this is the case.
[0] I wonder if the Unix people will drop on me like a ton of bricks for
using these two terms synonymously?
--
:: paul
:: we're like crystal
