You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Why are Finder alias files so huge lately?

Why are alias files so big now? Before (OSX 10.3), they were rarely bigger than 1 KB, but now (OSX 10.7), they're often up to 1.6 MB! Can we do something to keep them small?


As I understand it, an alias is just a pointer or reference to another file. When you open or print it, the operating system actually opens or prints the original file referenced. All that needs to be stored is the directory path to the original file, either (or both) as a full reference or a relative reference, plus its file system ID and perhaps a drive ID (in case it's moved). This should take only a few bytes. On prior Mac operating system versions (e.g., 10.3.9), these alias files were just a few hundred bytes in size, rarely over 1,400 bytes total. But now I notice that, under Mac OS 10.7, newly created alias files are always hundreds of KB large, and can typically be as huge as 1.6 MB! The custom icon only accounts for a fraction of this size. However, sometimes they can still be as small as before (only a few hundred bytes). Old aliases from a prior OS version (usually but not always) still work in opening their original file, so apparently we don't need the extra size. So, what is in these files?! I know these are analogous to "shortcut" files under MS Windows, which are not that large.


Having aliases be so huge defeats the purpose of a small file reference that can be used in multiple other places. One would like to use an alias so as to not have to keep a copy of a large file. But I notice that MB-sized aliases are often created even when the original file is a tiny 1 KB file. Moreover, a larger original file might create a smaller alias than that for a smaller original file, even when both original files are in the same folder. What gives?


I use aliases extensively, so as to keep references to the same original file in multiple folders, since these files fall into the multiple categories that each folder contains. By using aliases, I ensure that there is only a single "master" version that is edited when a file is opened from any of those folders. Many of the original files are pretty small, yet their aliases are many orders of magnitude bigger. This is very discouraging towards using this handy feature. Is there something I am doing wrong to end up making them so big – perhaps a system setting? What is in these files that they need to be so huge?


I suppose I can use Unix symbolic link files by using a command line in Terminal, such as 'ln -s originalfile linkfile', but these are less functional, since you can't move or rename the originalfile without breaking the linkfile's association to it.

iMac, Mac OS X (10.7.4)

Posted on May 29, 2012 11:59 AM

Reply
28 replies

Jun 8, 2012 3:48 PM in response to softwater

I am not convinced that these larger alias files have much to do with icons at all.


For one, I cannot delete the icon after I select it in the alias file's "Get Info" windoid.


Secondly, for other types of files, when I do delete their custom icon in that file's "Get Info" windoid, it does not reduce the size of the file all that much.


Thirdly, it would be a trivial matter for the Finder code to simply follow into the file that the alias points to and grab the original file's icon to display it as the alias' icon (and then draw the little arrow badge on top of it), just as if it were displaying the icon for the original file in its original folder, even if it's a custom icon (instead of inefficiently storing a copy of the icon within the alias file).


But beyond these points, my testing doesn't show that icons are the issue here…

Using two Macs – one running OS 10.7 and another OS 10.3 – and a USB drive (so I can move between the two Macs), I create an alias to a folder on the USB drive using the older Mac, and it is only 840 Bytes in size; but when I create an alias to that same folder on the same USB drive using the newer Mac, it is 680 KB (689,607 Bytes), instead – that's 821 times larger! I find it does similarly with all kinds of other files and folders.

I can also prove this with another method: By using the Finder on the newer Mac to "Connect to Server" (K) on the older Mac, then creating an alias on the older Mac via the newer Mac (which uses OS 10.7) makes a huge alias, whereas creating an alias of the SAME file/folder directly on the older Mac makes a much smaller alias.

The two aliases for the same file/folder created by both OS's – both (small and huge) aliases behave the same way: They both open to the same file/folder; they both show that their original file/folder path is the same; the icon for both aliases looks exactly the same on both Macs, even at maximum magnification. And they behave the same way on both OS 10.7 and 10.3. So, what do we gain with the bigger alias files created by newer OS's?!


What would really be useful is if someone actually cognizant of the Finder code that handles aliases contribute to this discussion… Is there anyone out there who actually works at Apple's OSX development team?

Jun 8, 2012 6:00 PM in response to DeathAllShare

DeathAllShare wrote:


Is there anyone out there who actually works at Apple's OSX development team?

Nope. This is a user-to-user support forum. You will never see an Apple-employed developer here.


The problem is that these new alias files aren't alias files at all. They are bookmark files, a completely new format. To maintain compatibility with old code, they still have the old alias resource fork. The use new technologies in the future, they have much of the same data repeated in the data fork. This is the cost of upgrading operating systems.

Aug 14, 2012 7:46 AM in response to DeathAllShare

DeathAllShare wrote:


...
I suppose I can use Unix symbolic link files by using a command line in Terminal, such as 'ln -s originalfile linkfile', but these are less functional, since you can't move or rename the originalfile without breaking the linkfile's association to it.

In fact you can, and if you don't wish to change the location of the original item, that's a good solution. The alias then is only 4 kB 🙂

Oct 17, 2012 12:13 AM in response to DeathAllShare

An effective solution to the large file size of aliases:


Any aliases I make to folders come out at 1 MB each. I suggest that this large size is due to the icon images contained in the alias file.


I say this because you if use the software CandyBar (which allows you to change the Mac's default icon images to differnt styles), and use the "Float" icon style that comes with CandyBar (you only need to use this style for your folder icons), then thereafter, you will find all new folder aliases have a much reduced size: just 164 KB.


CandyBar is now completely free, as the company is has provided a serial number that anyone can use to unlock CandyBar, and that number is: PPQA-YAMA-E3KP-VHXG-B6AL-L

Apr 27, 2013 2:13 PM in response to DeathAllShare

A solution to shrink an Alias down to 6 KB (in Mountain Lion, but it will work in Lion or Snow Leopard as well).


The "bad" news: it's a multi-step process, and it requires at least one shareware (i.e. non-free) application to handle one part of the process.


The good news: it's possible to automate a major part of the shrinking down to a single Finder keyboard shortcut, plus one click on a button, plus a warning confirmation. (The latter part could be probably automated even more by using an AppleScript and a terminal command while also bypassing the "shareware software step", but I didn't look into it yet.)


The solution until Leopard (OS X 10.5) used to be a simple but effective Contextual Menu Item plugin:

http://www.splook.com/Software/Shrink_Alias.html


Snow Leopard and later dropped the support for Context Menu plugins in favor of Services, so the plugin won't work out of the box anymore.


Additionally, I think since Snow Leopard (or was it in Leopard already?), apart from including the icon in the resource fork, an Alias now also includes the same icon in the data fork, effectively doubling its size. Sigh.

And the Shrink Alias plugin wasn't ever updated to handle the data fork anyway.


But there's a workaround to make Shrink Alias – and other old Contextual Menu Items – run nonetheless:


  1. Open your ~/Library folder. It's invisible by default, but you'll get there from the Finder "Go" menu while holding the Option key.
  2. In your Library folder create a folder named "Contextual Menu Items".
  3. Place the ShrinkAlias.plugin in there.
  4. Download and install the free Shortcuts application from Abracode: http://free.abracode.com/cmworkshop/shortcuts.html
    There's actually two of them in the download and you may want to install both. For running Shrink Alias you need Shortcuts32.
  5. Read the Shortcuts instructions on their webpage carefully.
    (I have also noticed that you may need to add background apps ShortcutObserver and ShortcutObserver32 to your Login Items manually since the corresponding Setup command doesn't stick sometimes.)
  6. In the Shortcut32 "Menu" tab you should assign a global shortcut to actually invoke the context menu in Finder.


Now the actual shrinking:


  1. When you select an Alias in Finder and press your shortcut from step 6, you should now see a contextual menu with the Shrink Alias menu item. Selecting it will already reduce the Alias size by one half, by removing the icon data from the resource fork.
    But there's still the data fork… 😟
    You need an application which can edit file forks.
    I know of two shareware options:
    Path Finder – an extremely powerful file browser, many people are actually using it as a full Finder replacement.
    File Utility from Limit Point Software – a relatively easy to use "one trick pony".
  2. Both apps support the OS X Services.
    • You can either use Path Finder's "Show Info" global service to open its File Info window, where you need to activate the Attributes: Dates/Forks section and delete the Data Fork.
    • Or you can use File Utility's Delete Data Fork service to invoke the app's interface for the selected item. (Note that you may want to disable all its other "Delete XY" services in the System Preferences, in order to prevent accidental file damages.)


Further automation is possible by assigning Services keyboard shortcuts in System Preferences, and by using a macro utility like Keyboard Maestro. As mentioned at the beginning, it should be even possible to automate everything using Applescript and Terminal commands and compile it e.g. as Service plugin using the OS X Automator. But that requires further investigation. 🙂

Apr 29, 2013 6:49 AM in response to Lukas

Thanks for your instructions!


I just found another solution to delete the data fork, in a simple way: Delete Data Fork 1.10

http://mac.softpedia.com/get/Automator-Actions---Workflows/Delete-Data-Fork.shtm l (free 🙂)

The installation is explained there. After installation, the contextual menu shows "Delete Data Fork" under "Services" at the bottom of the menu list

Apr 29, 2013 7:03 AM in response to fandumac

Great, cheers!

That's in fact exactly what I meant by:


The latter part could be probably automated even more by using an AppleScript and a terminal command while also bypassing the "shareware software step", but I didn't look into it yet.


The workflow obviously uses a shell script to delete the data fork. Since I have no clue about writing shell scripts, only some basic AppleScript knowledge, I couldn't write stuff like this myself anyway. Although I'd knew what I should be searching the web for… 🙂


But as it says on the download page:

WARNING: Make sure you know that what you're deleting is not important file data!

In other words: everyone who dares to use this workflow should exactly know what they are doing!

(Y'all have been warned…)

Nov 6, 2013 4:11 PM in response to DeathAllShare

I am sorry for any inconvenience if it turns out that I don't understand this issue. Please, can anyone confirm the following: in MacOS (in my case 10.8.5) there is no such thing as a simple shortcut (a simple tiny pointer to a file) like there is in Windows?


What is all this fuss about megabytes-long files that should just point to a location?


Am I missing something huge here?

Sep 24, 2014 6:06 AM in response to fandumac

@fandumac: Pls clarify what you mean by "In fact you can".


Also, I'm under the impression that I need to use the cd (Change Directory) command in Terminal first. And then, use the ln command described above, correct?


In doing this, I copied the path of where the originalfile is located and pasted it on the command line (following the 'cd ' command), but it's not working (error msg claims that it can't find it).


I know the path is correct b/c it's the same one in the Get Info for the file...I even created a shortcut on Finder's Right click menu to Copy the Path to the Clipboard (so all i have to do is Paste it in Terminal), but still not working.


Any ideas on how get this to work, or to simplify the process somehow? Is Terminal the only app that can perform the Unix Symbolic Link function or can it automated somehow?


Thanks!

Why are Finder alias files so huge lately?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.