Home Forums Mac Software Mac Operating Systems Size of aliases?

I know aliases are not always a small as we'd expect them to be, but I'd love some sort of explanation for the sizes of these four on my Desktop:

1. Excel file: 25Kb / Alias: 4Kb

2. Excel file: 147Kb / Alias: 49Kb

3. Folder of PDFs: 709Kb / Alias: 1Mb

4. TextEdit doc: 8Kb / Alias: 98Kb

Thanks.

My guess would be it's representing differences in the size of the icon resources for each alias. Some may have less resolutions or be simpler in appearance and more compressible in data size.

FWIW I am getting the same kind of results here. It is shocking to find the alias of smaller files is often bigger, sometimes substantially bigger, than the original file.

To test Kevin's icon theory, which seemed quite reasonable to me, I created a series of aliases of the same .doc file with the following results:

• SIze of the original doc: 106KB
• Size of the first alias created: 508 KB
• Size of the second alias: 655 KB
• Size of the third alias: 655 KB
• Size of an alias of the third alias: 664 KB

Since all of the aliases have the same icon that would seem to eliminate that theory.

At this point I suspect that until someone has the time and patience to go rummaging through the deepest bowels of BSD Unix and the OS X developer's documentation, the reason for the varying alias sizes is going to remain an inexplicable phenomena.

For now the moral of this seems to be that in order to conserve disk space you might be better off using "smart folders" instead of aliases to organize your files. (Hmmm? Maybe I better test that theory before propounding it.)

> To test Kevin's icon theory, [....]

I, too, tested (on my TextEdit doc), and the progression went 8K...98Kb...360Kb...360Kb...360Kb... Strange!

> For now the moral of this seems to be that in order to conserve disk space you might be better off using "smart folders" instead of aliases to organize your files.

I'll see your "smart folders" and raise you a (CMI) Service...

I d/l'ed SymbolicLinker (Freeware), and replaced my four aliases with symlinks, each of which is 4Kb (40-50bytes).

This is not about disk space, mind you, but about the horrible "aesthetics" of those aliases.

Edit: I forgot to mention that you can't control-click and color a symlink's label as you can do with an alias...no big deal, but I wonder why?

Weird. Whenever I make multiple aliases of the same file all my file sizes for the aliases are exactly the same. Since I'm stuck with Leopard, maybe it's different in Snow Leopard?

I just booted into my Leopard partition and got the same results you did... My 8Kb TextEdit doc generated 5 aliases of 48Kb each four times straight (except for one 172Kb weirdo in the first batch that could not be reproduced).

Have I tripped over yet another bug in SL?

please remember that aliases are represented with resource forks, even in snow leopard. open them up with a tool like Resourceror and have a look see as to why they vary in size.

Looking at one resource here on my desktop I see:
<DF> 507k (the entire resource fork taken as a whole)
alis one record, 320 bytes
icns one record, 506k

so the majority of the alias size is indeed the icon, as would be expected. The 320 bytes is the usual os x alias record data block.

The reason for the size difference is probably related to the number of members in the icon family. Aliases have to copy the icon, whereas files with extensions don't even have to have the icon. So for example, a .rtf on your desktop with Hello World in it may be under 1k, yet its alias could easily be 500k, because it has to store a copy of the icon whereas the rtf does not.

Icons that look alike don't have to BE alike. One may for example, have only the "jumbo" 128x128 in them, and finder is merely scaling it. It may be missing the 64x64 family member or any others. hard to say without opening it with IconGrapher etc.

So, comparing two aliases from different documents, they could be the same size, close, or completely different, all based on the original file. The size of the alis record is insignificant compared to the icon.

For the terminal monkeys:
you can do a cat on the alias, but add "/rsrc" to the end. Better pipe it through xxd or it won't be pretty.

cat ~/Desktop/testfile/rsrc | xxd -c 48

where "testfile" is an alias on your desktop. /rsrc has been a standard way to access raw resource forks from the start. Terminal does NOT resolve OS X aliases, ever.

OK... But why are symlinks, which serve the same purpose as do aliases (for me, anyhow), so much smaller than their equivalent aliases?

And are you able to explain the progression of sizes of aliases in SL as opposed to the static sizes of those in Leopard?

This doesn't address the question of why Snow Leopard may produce aliases of different sizes for the same original, but there was an interesting discussion of the phenomenon of inexplicably large aliases over at 'Hints: Why are aliases different sizes. (That thread features Hal Itosis in full gadfly mode, which may help offset his thus-far conspicuous absence from the topic here.)

> (That thread features Hal Itosis in full gadfly mode, which may help offset his thus-far conspicuous absence from the topic here.)

Is Hal, perhaps, away on his annual hiatus?

But why are symlinks, which serve the same purpose as do aliases (for me, anyhow), so much smaller than their equivalent aliases?

There are two kinds of links in unix. Soft ("symbolic") and Hard. Any file on the hard drive has its main directory entry somewhere in the directory structure on the hard drive. That record points to the first or map block of the file on the hard drive.

A hard link is a copy of the directory entry, in another place. It takes up no space except in the directory. It refers to the file by an ID number, and as a result the file can be moved or renamed and not affect the link. If you try to update a file by deleting it and writing a new one in its place with the same name, it can break the hard link because the file id changes.

A soft link holds a string that is the path to the file. The file cannot be renamed or moved (or ANY folder in the tree renamed or moved) or the symlink will not follow it and will point to a nonexistent file. But the file can be deleted and replaced with a new file, and the symlink will work with the new file.

So the two types of links behave in very opposite ways and are used for opposite reasons.

The soft link requires space to store a string of what may be a very long pathname, so it requires filespace. The hard link does not since it's just a directory entry. So a hard link basically requires no disk space, and a soft link requires very little space. No icon information is stored in either. For MOST purposes, referring to a link (soft or hard) in unix (a la console) behaves exactly like accessing the original file. You have to be careful with links... I started using a homemade backup script many years ago after I tried to delete a hard link to a file, and terminal ended up deleting the original instead of the link. (no backup) Time machine iirc uses hard links to save space. Instead of making a new copy of a file for each backup version, it just hard links to the original first copy. An entire backup of your hard drive may take as little as 30mb, existing entirely of directory entries of hard links. If you dig into the backups db of time machine you will see a lot of files with the little arrow on them, those are NOT aliases, those are links.

Mac OS X aliases appear to be a combination of the two, in one file. Because of this, you can move, rename, OR replace a file and the Finder will continue to follow it. But if you do BOTH without Finder interacting with it, it can lose track of it. It tries to stay on top of things though. Lets say you make a file in your documents folder, and put an alias to it on your desktop. Then you rename the original. Then you try to double click the alias. Finder will probably try the hard link copy first, and finds the file. But it notices the pathname has changed. So the alias file will get updated automatically with the new soft link. The same happens if you try to replace the file with a new copy (as many Save operations do), the hard link fails but the soft one works, so the hard link gets updated. I believe there may be a third mechanism at work also. Aliases have worked this way in mac os since the beginning, before unix. Mac OS X aliases CAN store icons, although in the last several weeks 10.6.3/4 have given me considerable grief in keeping icons working properly. So aliases are the biggest of the bunch, as they store a hard link, a soft link, and also an icon. I think ALL aliases store icons, even if the original file has no icon. If you try to get info on the alias and delete the icon, it just copies the default / original icon in from the file or the original bundle.

Unix (a la console) is not aware of Mac OS alias files and cannot resolve them to open files or traverse folders. I'm surprised Apple has never added support for them in terminal.

Interesting quirk with aliases... if you make a document, then make an alias to it, then copy the icon of the alias and paste it, the little arrow of the alias gets copied. When an alias gets its icon, the arrow is rendered onto the icon before it is stored in the alias, not during the render on the desktop.

somewhat OT, iirc, every file has at least one hard link to it, it's original directory entry. If you start creating additional hard links to the file, the "valance" of the file is said to increase. So a file with a valance of 3 has three directory entries that represent it. It really doesn't matter which was first, they all are effectively the same, there aren't one original and two aliases, there's just three entries, in no particular order. When a file's valance drops to zero, the file system deletes it. If for some reason it fails to get deleted, it's an 'orphan' and apps like diskwarrior can sometimes recover them. Hard links and soft links do not have to use the same name as the original file nor do they have to be the same as each other.

Good and informative answer V1. This might be a candidate for a Frequently Asked Mac Question. Although it does not address a troubleshooting question per se it is informative and might answer some of those "always wanted to know but afraid to ask" questions we all have.

Here is the <alis> resource from an alias on my desktop:


(the data fork was zero bytes)

The actual alias itself is quite small compared to the icon in it. So unless this accounts for your size difference, (guessing not) the difference is in the icon. Perhaps its rendering Jumbo or256x256 icons in SL for icons? (the entire alias is 48k) I'm sure there's some documentation as to the format of the <alis> record, but I'd be willing to bet the format hasn't changed much at all for a very long time. perhaps back into os 8.

Aliases have nothing in common with hard links.

An alias record contains whatever information is needed to locate the original target. How much information is required depends on where the target is located and how the alias is created. An alias to a file on a network server contains much more information than an alias to a local file, since using the alias may require reconnecting to the server and remounting the remote volume; a relative alias stores less information by giving up the ability to track a file that moves. The program creating the alias record specifies how much information should be included.

An alias record is now considered an opaque data type. How much information it contains, and in what format, is undisclosed and subject to change from one release of the OS to another.

An alias record would typically contain:

• The path to the target (essentially a symlink, either relative or absolute).
• The directory ID (the HFS counterpart to an inode number) for every directory in that path)
• The file ID (the HFS counterpart to an inode number) for the target itself. ("directory ID" and "file ID" are synonyms for "CNID (Current Node ID)".)
• Enough information to identify the volume. Originally, this was at least the name, size, and creation date of the volume; any volume agreeing on two out three of these would be considered a match. The volume type (floppy, hard disk, network mount, etc.) was also included, and had to match. Other information may be present as well, if relevant: the volume's GUID if it has one; an alias to a disk image file the volume was mounted from; a URL to a remote volume; etc.

An alias record can appear in many different places: in memory for temporary use, in an AppleEvent, on the clipboard, in preference files, etc. One particular use of an alias record is in an alias file, wherein it is stored as an 'alis' resource.

Responding to you as the last poster and to V1 as well...

Thanks to both of you for clarifying aliases, soft links and hard links, but neither of you has addressed the question of why aliases of the same file, created one immediately after the other in OS X 10.6.x, wind up being of progressively, and then assorted, larger sizes.

It sure doesn't smell like expected behavior...more like a rat; is it, in fact, a bug?

Artie since you seem convinced this is a bug have you submitted it to Mac OS X Feedback? Personally, given the complexities of all that is included in the alias file, I think that only the Apple developers can determine whether or not it is a bug.

According to my tests, the only way to get the widely varying sizes reported above is that you are taking aliases of aliases.

If I repeatedly make aliases of the same file, they're all the same size.

The alias of a file needs to hold a copy of icon for the original file, even if the original file was not itself holding a copy of its icon. (A document's icon is usually synthesized on the fly from information provided by its application. An alias doesn't have that privilege, since the alias may be moved to a volume from which the original application is not visible. This allows the alias to auto-mount the volume when it's resolved, but still display the correct icon without the nuisance of a premature auto-mount.)

I selected a random .rtf file, then pressed command-L repeatedly to make a chain of aliases, each pointing to the previous alias:

As you can see, the 'alis' resources grow slightly, largely due to the changing sizes of the names of their targets.

The big change is the size of the 'icns' resource. The original file doesn't have one, the alias to it does, but an alias to an alias contains a larger' icns' resource than the original did. Successive aliases of that have somewhat smaller 'icns' resources.

The extended attributes (@) on the aliases is Finder Info: type=alis, creator=MACS, attribute bits A (alias) and C (custom icon) have been set.

Curious to know why the 'icns' resources get slightly smaller each time, I finally put the Finder window in icon view, and turned off the "Show icon preview" view option.

The original document has a generic "RTF" document icon, not actually stored in the document.

The first alias acquires its own copy of the generic icon. The curved-arrow badge that marks it as an alias is not actually stored in the file, but is added dynamically by Finder when it renders the icon. (If you copy the icon from a Get Info window on the alias, you get what you see: the icon with the badge, not the icon as it's stored in the file.)

The second alias acquires a copy of the icon from the first alias, which this time is a composition of the generic icon plus the badge. The composited icon is larger than the generic icon, since the badge is placed in a previously-transparent region of the icon. In the process of adding the badge, the original icon is faded ever so slightly. If you blow up the icons, you see this as a slightly jaggier letter A in the upper left corner of the "RTF" icon.

Each successive alias adds the badge again, which doesn't by itself change the size, but again slightly fades the previous icon. With less contrast, the newer icons compress better, explaining the gradual drop in 'icns' sizes.

> According to my tests, the only way to get the widely varying sizes reported above is that you are taking aliases of aliases.

That is precisely what I was unthinkingly doing.

> If I repeatedly make aliases of the same file, they're all the same size.

Yep!

Thanks for the insightful and comprehensible explanation of the "phenomenon."