On Nov 12, 2012, at 3:51 PM, Alex Zavatone < email@hidden> wrote: We don't need megabytes of icons within pointer files.
You need megabytes of icons for anything that you want to be gorgeous on a retina display. Even if it's "just" a pointer file.
The multi-megabyte icon has to be IN the file, if there's a chance the file will be moved far from where the icon normally lives. "Far" means roughly "over a slow connection or over a connection that's only sometimes a connection". (For example, over a network, or on a floppy disk that is only sometimes mounted.)
Documents don't need to contain icons, because documents never stray very far from their applications (or when they do, you actually want the icon to become generic, to advertise that it cannot be opened).
Symbolic links don't need to contain icons, because they never stray far from their targets (or when they do, they become useless).
Alias files do often get moved very far from their targets, and yet will make extraordinary efforts to make the connection anyway. We just don't want it to go the the trouble of making the connection just to display an icon, so we cache the icon.
I actually have some aliases somewhere that are LARGER than the file they point to. I don't know how that is even possible.
It's easy, and has been explained many times. The target may not need to contain its own icon, because it never moves far from wherever the icon started out. (For example, a document can get its icon from its application, which is not far away.) The alias file does, however, need to contain its own copy of the icon, because the alias file can be moved very far away from its target.
Oh, wait. I just made an alias to the AFNetworking class folder that I just downloaded. AFNetworking: 340 KB Alias to AFNetworking: 1 MB
That sucks. I don't care if anyone thinks it doesn't. That simply sucks. Advantage defeated.
If the ONLY advantage you wanted is a pointer file that can only point at a nearby folder, then use a symlink. The symlink will be useless, however, if it isn't pointing to something on a currently mounted volume. Because the target of a symlink is so near, Finder can get the icon for the target at nearly zero extra cost, and use that.
In any event, saying that the size of the alias file defeats its advantage is hyperbole. It still works just fine, doing everything it's supposed to do, even if it's a little larger than you would like. (And no, copying the target instead of making an alias would not solve the problem. While the copy could be smaller than the alias, there are many situations where it's vitally important that there be only one original. With copying, you need version control or a reserved suite at the local asylum.)
Certain placeholder graphics are fine.
It would be a single placeholder graphic. Without resolving the alias, there's no clue which placeholder graphic to use. It would be the same graphic for folders, applications, documents, servers, etc.
And, many users would complain that their aliases have lost all their icons. Most people don't care about a few MB of cache space on disk.
The only reason the topic has come up is that an alias file puts its cache right there in the file, where it sticks out. Shoving the cache into a Desktop database, or a Launch Services database, or into a .DS_Store file, or somewhere in a Caches folder would take the cache space out of sight, and we wouldn't need to be having this discussion, but wouldn't save any disk space.
But it creates a cumbersome solution that causes additional problems - that of file bloat.
At the time the solution was created, icons were small, and files couldn't physically be smaller than 4KB, so the icon was actually free.
The only "bloat" is that we now want everything to be prettier than they were in the bad old 8-bit blocky graphics era. If a folder has a few hundred alias files, then the requests should go through a manager to manage the display of the requests for that folder's contents, weed out the duplicates and only fetch what is needed.
We don't get to rewrite history. Aliases were introduced in System 7. The "manager" was the Finder, and machines could not support the sort of multi-threaded background processes you're envisioning. Hey, at the time we were grateful that System 7 finally allowed beep sounds to play in the background without locking up the system. This "every file knows how to get its own icon through a file or network thread" explicitly causes this problem.
It would cause the problem if we did that. Alias files carry a copy of their icon specifically so they do NOT have to get their icon over the network (or worse, demand that a disk be remounted so you can get the icon). Don't let my comments about floppies make you think the issue is no longer relevant. An alias file can target a file on a CD or DVD. Try to fetch such a target's icon without annoying the user.
-Ron Hunsinger |