Why do alias sizes vary so greatly?

Discussion in 'Apple' started by Nick Naym, Aug 17, 2009.

  1. Nick Naym

    Nick Naym Guest

    In Classic, aliases always were 4K. In Leopard, they're all over the place:
    from as little as 4 K to hundreds of K. I've also noticed that even when the
    created alias is only 4K, simply changing its name slightly (by adding a
    character, or simply deleting the word "alias" (if it has been appended as a
    result of using cmd-L to create it instead of option-cmd-dragging the
    original) causes the size to jump by factor of 10 or more.
     
    Nick Naym, Aug 17, 2009
    #1
    1. Advertisements

  2. Nick Naym

    David Empson Guest

    Icons.

    Mac OS X will copy the icon of the original file into the alias file, so
    it can display the correct icon even if the original file is missing.

    I've confirmed this with one particular alias file currently sitting on
    my desktop. The file is about 48K, of which 576 bytes is the 'alis'
    resource (Alias) and the rest is an 'icns' resource (Icon Suite).
     
    David Empson, Aug 18, 2009
    #2
    1. Advertisements

  3. Are you then implying also that if you change the original of an alias
    to something with a different icon, its icon shall change and
    consequently, its size as well?
     
    Thomas R. Kettler, Aug 18, 2009
    #3
  4. Nick Naym

    David Empson Guest

    Usually only if you are using old file systems like HFS and FAT16. For
    example, on a 1 GB volume, HFS has to use blocks of at least 16 KB.

    For HFS+ (Mac OS Extended), a 4K block size can be used on volumes at
    least up to the hundreds of gigabytes range, and probably into the
    terabytes range (don't have my one handy to confirm). As drives get even
    larger we will eventually reach a point where HFS+ has to start using 8K
    or larger blocks.
    Spotlight doesn't modify files. It only gathers information about files
    and stores it in an index.
     
    David Empson, Aug 18, 2009
    #4
  5. Nick Naym

    David Empson Guest

    No, just that the alias contains a copy of the icon.

    It appears that Finder's logic is along the lines of this:

    "If an alias is modified in any way, and it doesn't currently contain an
    icon resource, then copy the icon from the original file into the
    alias."

    If the original file's icon changes, the alias still has the previous
    icon.

    I tried changing the icon on an original item and then modifying the
    alias (by renaming it), and opening the original item via the alias.
    Neither of these updated the icon in the alias.

    I was able to remove a custom icon on the alias (which had been copied
    automatically from the original file) by doing a Get Info on the alias,
    selecting the icon and pressing the delete key, but I couldn't find a
    way to force Finder to update the icon to a custom one which had
    subsequently been applied to the original file (short of creating a new
    alias).
     
    David Empson, Aug 18, 2009
    #5
  6. AFAIK, HFS+ allows 2^32=4,294,967,296 blocks versus the 2^16=65,536
    blocks of HFS. At 4K per block, that allows one to have a 16 binary
    Terabyte hard drive without having to increase the block size. I have a
    3 decimal Terabyte (2.73 binary Terabyte) LaCie hard drive and each
    block is 4K (732,485,314 blocks in total).
     
    Thomas R. Kettler, Aug 18, 2009
    #6
  7. Nick Naym

    Nick Naym Guest


    ....
    ....

    Hmmm...

    I just made an alias of a 148K file -- a pdf copy of a 3-page magazine
    article (icon is a miniature of the magazine article's first page) via
    cmd-L. The alias is a 4K file.

    I then created another alias of the same file in an empty folder by
    optn-cmd-dragging it into the folder's open window. That alias is 164K.

    I repeated the same exercise with a 150 MB folder (icon is OS X's standard
    generic folder icon) instead of the pdf file. This time, both aliases were
    the same size: 508 KB.

    Seems there's more to it than just the icon.
     
    Nick Naym, Aug 18, 2009
    #7
  8. Nick Naym

    Nick Naym Guest

    ....
    ....

    This is fascinating: I repeated the above all over again. This time, the
    aliases created by cmd-L initially were _both_ 4K...but just by selecting
    them and beginning to move them (without actually doing so) their sizes
    immediately changed to that of the aliases that got created by
    option-cmd-dragging the originals into that empty folder (i.e., they changed
    from 4K to 164K and 508K, respectively).
     
    Nick Naym, Aug 18, 2009
    #8
  9. Nick Naym

    AES Guest

    Try closing the folder (before doing the name change), then re-opening
    it, and you may see the same result.

    I use several apps that export a file to a folder, or process a file in
    a folder and return a processed file to the same folder. If I'm
    simultaneously watching that folder in List mode, I often see a very
    small file size for the new file listed initially -- I'm guessing this
    results from the initial creation of some kind of "placeholder" file?
    Closing and re-opening the folder instantly changes this file size to
    the real (much larger) file size.
     
    AES, Aug 18, 2009
    #9
  10. Nick Naym

    David Empson Guest

    Not quite that many, but in that order of magnitude. I'd have to check
    the specifications again, but I think the maximum number of blocks per
    HFS+ volume is somewhat less than 2^32. Even if it is 2^31, that is
    still 8 TB with 4 KB blocks.

    The operating system may impose a somewhat smaller limit for performance
    reasons, so it doesn't have to deal with an enormous allocation table.
    2^32 blocks would require 536 MB of RAM, unless it caches pieces of the
    allocation table.
    Good to know we haven't hit the limit as of between 2 and 4 TB, anyway.

    Your allocation table will be occupying about 91 MB of RAM, in theory.
     
    David Empson, Aug 18, 2009
    #10
  11. Nick Naym

    David Empson Guest

    There is nothing else involved. It is just the icon.

    I just did the same thing, with the same reuslt, and examined the
    contents of the alias again.

    An alias to a folder is 508 KB because the icon for a folder (in
    Leopard) is 506 KB. It includes a 512x512 icon.

    There is nothing in the alias to the folder apart from the 'alis'
    resource (426 bytes in this case) and 'icns' resource.
     
    David Empson, Aug 18, 2009
    #11
  12. Not according to Wikipedia. Wikipedia indicates 2^32 for the number of
    blocks.

    You're indicating RAM. Don't you mean hard drive space? The Allocation
    File is found on the hard drive.

    Of course, it is funny that part of the Allocation File will indicate
    that the blocks of the Allocation File are in use.
    If you're using 91 MB=91,000,000 bytes, you're correct. The allocation
    file on the hard drive has 22,354 blocks=87.3 binary MB on the hard
    drive.
     
    Thomas R. Kettler, Aug 18, 2009
    #12
  13. Nick Naym

    Nick Naym Guest


    How did you do such a confirmation?
     
    Nick Naym, Aug 18, 2009
    #13
  14. Nick Naym

    David Empson Guest

    But a large proportion of it (if not the whole thing) will be loaded
    into memory, because it is being frequently accessed by the OS to locate
    free space whenever a new file is written or an existing one grows
    outside an allocated extent.

    I expect it would be managed via the virtual memory system. You could be
    using as much as 512 MB of RAM to hold the allocation table for 2^32
    blocks.

    It must also be written back to disk whenever the disk is synchronised.
    Yes, yes. I was being lazy.
     
    David Empson, Aug 18, 2009
    #14
  15. Nick Naym

    David Empson Guest

    I used a resource editor to look inside the alias files.

    I have Resorcerer, which is a rather expensive (US$256) programmer's
    resource editor dating back to Mac OS 9 (and earlier), which was updated
    to run on Mac OS X. Unfortunately not a Universal Binary, and it hasn't
    been updated for several years (my copy of version 2.4.1 is dated 2002).
    Now mostly obsolete because resources aren't used by modern Mac OS X
    applications.

    There are other tools which can pull apart resource forks, e.g. the
    developer tools include a command line "DeRez" tool. If given the
    -noResolve option it will not try to resolve an alias, so it will be
    able to extract the resources from an alias file.
     
    David Empson, Aug 18, 2009
    #15
  16. Nick Naym

    Wes Groleau Guest

    I don't know how they do it, but aliases keep track of the file they
    point to. So you can move the file and the alias will still work.
    Does that mean there is a database, either in one spot or distributed
    among the target files' resource forks, a database that tells where all
    the aliases are? Or does each file have some sort of identifier in its
    directory entry that the alias refers to? Does that mean resolving an
    alias requires searching all directories for that ID?

    Or is there an explanation I haven't imagined that takes far less resources?

    I use softlinks or hardlinks myself. A softlink is _always_ 4K, and
    almost all of that is empty. A hardlink is merely an inode. Finder
    displays the actual file's icon for either. And if the file is removed,
    I see no benefit in having the alias look like it hasn't been removed.

    If I put the file in its most logical location, why would I ever want to
    move it, much less worry about forgetting where I moved it to?

    If I put it in an illogical place, ... wait, I wouldn't do that. :)

    OK, of course I _could_ be careless, or change my mind about what's
    logical, but then I've got 'find' and Spotlight.
     
    Wes Groleau, Aug 19, 2009
    #16
  17. Nick Naym

    David Empson Guest

    No. Aliases are self contained and nothing else refers to them.
    Yes.

    On an HFS or HFS+ volume, every directory and every file has a unique
    identification number. The alias stores these as well as other pieces of
    information it uses to locate the original file or folder.

    An alias will automatically follow a file or folder if you move it to a
    new location, even if you rename it or any of its parent folders in the
    process. This is because the unique identifiers have not changed.

    If the original file or folder is deleted and another one of the same
    name is created in its original location, the alias will notice the
    replacement file and revise itself to refer to the new file (as long as
    you use the alias before the new file is also renamed or moved
    elsewhere).
    No. HFS and HFS+ use a modified "B-tree" directory structure which is an
    index for the entire file system. The system can very quickly locate
    files by directory ID and filename. If the target file has not been
    moved or renamed, this is faster than a pathname search (which requires
    finding and stepping through all the parent directories).

    If the folder containing the target file is renamed or moved elsewhere,
    the search is still instantaneous, because the parent folder's directory
    ID is unchanged and the filename is the same.

    If the target file is renamed but still in the same folder, the alias
    will go straight to the correct folder and then locate the file based on
    its unique file identifier (which will require processing directory
    entries for each file in that folder).

    If the target file is moved to a different folder, it is necessary to
    search the entire file system to locate it, by finding its unique file
    identifier. (I don't recall offhand if HFS+ maintains any kind of index
    to speed up this process, but Spotlight might help.)
    A soft link just contains the text pathname to the original file (and a
    flag in the directory entry to identify it as a soft link). If the
    original file moves, the soft link will still refer to the original
    location and won't follow the file. There are sometimes useful reasons
    to want this behaviour, which can't be simulated with an alias.

    Soft links are also useful for Unix tools, as they understand soft links
    but usually can't cope with an alias.
    Not on an HFS+ volume. Hard links are implemented in a complex manner
    which behaves like an inode on a standard Unix file system.

    On HFS+ they actually work by moving the original file to the hidden
    "HFS+ Private Data" folder and creating a directory entry which points
    to the real directory entry for the file. This only happens when a hard
    link is added to an existing file.
    Finder also shows an icon badge indicating an alias for an alias or soft
    link. A hard link is a standard icon.
    Apple's choice to copy the icon into the alias seems a little odd. It
    may have been done for performance reasons - it is faster to grab the
    icon out of the alias than look up the original file (which might
    require a search if the file had been moved), so the icon is effectively
    cached in the alias. It just isn't updated reliably.
    If I create a folder or file with some useful information, put an alias
    to it somewhere else (e.g. on my desktop or on my DragThing dock) then
    later decide I want to reorganise the original files, or rename them to
    something more appropriate, the alias will still work.

    Most of the things to which I have aliases aren't moving very often, but
    occasionally I change my mind when something else comes along which
    suggests amending a directory hierarchy to add more structure, or
    something like that.
    Those are a useful fallback, but I don't see any point mucking around
    with relatively slow search methods - the alias still works.

    Aliases have other useful features such as being able to refer to an AFP
    share, so opening the alias can mount the server.
     
    David Empson, Aug 19, 2009
    #17
  18. It makes a great deal of sense when you consider that aliases can be
    moved to different volumes. Having the icon cached is quite useful if
    the alias is to a volume that isn't mounted, such as a network share.

    I haven't had to worry about alias icons in a few years, so I'll accept
    that they're not updated reliably anymore. (In fact, I think I even
    remember that from the Mac OS X 10.4 days.) But in the Mac OS 9 days,
    the icon of aliases to files would change if you changed the original
    file's type or creator code, and chose "Show Original" on the alias.


    Steve
     
    Steven Fisher, Aug 19, 2009
    #18
  19. Nick Naym

    AES Guest

    (Very useful tutorial on aliases)

    Thanks much for writing this very useful tutorial, and helping us
    non-experts get a bit better understanding of the complexities that go
    into operating systems.

    You should put this on a web page somewhere (maybe you already have) --
    or start looking for a publisher? (maybe you already have).
     
    AES, Aug 19, 2009
    #19
  20. Nick Naym

    Tom Stiller Guest

    ls -l <filename>
    ls -l <filename>/rsrc
     
    Tom Stiller, Aug 22, 2009
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.