It's a reference to Sesame Street: http://muppet.wikia.com/wiki/Brought..._Sesame_Street!

The ∏ recalls the Greek yoghurt story.
I don't think there's anything special about the number 1011011001 - maybe he meant to refer to 11011000001

I'm always impressed by how much smarter I seem when people make the effort to interpret my totally random cr@p. :rolleyes:

Guess you're not using any sync services then (MobileMe or using an iPhone/iPad/iPod).



Yeah, a Snow Leopard "improvement"... not (IMO). A 'usro' resource gets added.



Note that using the -@ option with ls is a more convenient way of getting the sizes of files plus attributes:

ls -l@ /path/to/whatever



I agree, it's more wasteful than the former com.apple.FinderInfo location (only 32 bytes). As far as how many, i think it's just the ones on which the user tweaks Finder's "Open WIth..." settings.



bozo bit

I don't recall if you mentioned which version of the OS you're using, but I can tell from this (and the evidence that neither file has a non-empty resource fork) that it's not Snow Leopard. The only difference between them is type/creator, which Snow Leopard completely ignores.

The original use of these was:

• A "creator" code is a 32-bit value that is intended to uniquely identify an application. The 32 bits are usually meant to be interpreted as 4 printable bytes. To guarantee uniqueness, the application developer would register their code with Apple before shipping the application.
• A "type" code is a 32-bit value that identifies the format of the file. Type codes are not required to be unique, and in fact if the format is one that multiple applications can understand, they should strive to use the same type code. Like creator codes, a type code is usually thought of as 4 printable bytes.
• Certain type codes are "well known". For example, the type code for a plain text file is "TEXT", and for an application "APPL". I won't bore you with the full list of well-known type codes.
• Each application contains a "bundle", in which it identifies its registered creator code, a list of type codes for the formats it knows how to read, and an icon associated with each of those.
• When Finder wants to show an icon, it looks for the application with the same creator code, and looks in that application's bundle for the icon that matches the type code. If it can't find the application, or if the application doesn't define an icon for that type, then it uses a generic icon for that type.
• Except that a document can contain optional icon resources, that override the icon from the application.
• When you double-click a document, the application with the same creator code is the one that opens it. Applications typically put their own creator code in all documents they create (but can put in another application's creator code if they want that application to assume ownership of the file).
• Except that a document can contain an optional 'usro'(0) resource, whose value is an alias record pointing to an application. That overrides the creator code in determining which application to use.
• When you drag a document onto an application's icon, the application will accept the drag only if the type is one that the application's bundle says it can read. (There is a wild-card type that can be used to say the application can open any file type.)

OS X has a much more sophisticated way to accomplish all these objectives, and type/creator have only been grudgingly considered. Snow Leopard finally cut the apron strings, and completely ignores type/creator.

It still does not ignore icon resources or 'usro' resources. When you choose "open with..." and do not say "Apply to all documents of this type", a 'usro'(0) resource is added to the document, creating a resource fork to hold it if it's not already there. ('usro'=User Open).
There's no "moving" of type/creator to the resource fork. They have a hard-coded position in the catalog entry itself. The file never had a (non-zero) type/creator, and still doesn't need one. The 'usro' resource overrides creator, and any icon resources will override the type/creator combination. An OS X application is expected to be able to figure out the type of a file without needing an explicit type code (by, for example, looking at the filename extension).

Because type/creator are now being overridden, they can't be relied on to determine the correct icon.To preserve the icon, the file was given a custom icon, probably as an 'icns' resource. The 'has a custom icon' Finder flag also had to be turned on. (FinderInfo starts with 4 bytes of creator, 4 bytes of type, and 2 bytes of Finder flags. 0400 is the bit in Finder flags that indicates a custom icon.) 'icns' resources are huge.

If you want to see what's in the resource fork, you can use:

# Just list the resources and their sizes.
RezDet -list file

# List the resources and their values
DeRez file

Both commands accept a -useDF parameter to say the file's resources are in its data fork instead of in its resource fork, but still in the format expected in a resource fork. (Such a file would typically have a .rsrc filename extension.) This is to allow resources on filesystems that don't support resource forks, at the expense of having to store data and resources in separate files.

Each resource is uniquely identified by a 4-byte "resource type" and a 16-bit "resource id", conventionally written as 'type'(id). Each has an optional "resource name" and 8 bits worth of "resource attributes", which may be written between the id and the closing paren, as in 'type'(id,"name",attributes).