Idle Time

This bug is Preview uses its own made-up value for resolution of PostScript images. It was filed on 2006-04-07 at 00:45 PDT.

I discovered this bug when making the navigation buttons I donated to Simone Manganelli (you may recognize his¹ name if you’ve been reading the comments on this blog) for switching among his stylesheets. The PNG images that I saved from Preview showed up as 32×32 in the Finder. So I had to open the EPS file in Photoshop, which is how I found out that the resolution was wrong.

Summary:

PostScript documents can specify a resolution. Preview, when converting to PDF and then to raster format, ignores that value and uses 150 dpi instead.

Steps to Reproduce:

1. Open an Encapsulated PostScript (.eps) file containing an explicit resolution in Preview.
2. Save as PNG or TIFF.
3. Open the PNG or TIFF in Photoshop. (NOTE: This is incorrect. I meant to change this but forgot. See below. —PRH)
4. Choose “Image Size”. (NOTE: This is incorrect. I meant to change this but forgot. See below. —PRH)

Expected Results:

The resolution is as stated in the EPS file.

Actual Results:

The resolution is 150 dpi in a TIFF file, or 150.0124 dpi in a PNG.

Regression:

None known.

Notes:

The Document Structuring Conventions, upon which EPS is based, provide for a resolution in the optional “Requirements” comment. For example:

%%Requirements: resolution(x,y)

Preview appears to target a specific length in real-world measurements (inches or cm). Not only does it force the resolution to 150 dpi, it also rasterizes the image at double-size (which compensates for the resolution change, but only in applications that pay attention to the DPI — which are not many, at least in the case of PNG files). This is symptomatic of Preview converting to PDF as an intermediary, as proven by using pstopdf and then saving the PDF as PNG or TIFF — it is still saved as 150 dpi, double-size.

The solution is twofold:

1. Rasterize at 72 dpi by default. This is the default resolution of PostScript, upon which PDF is based, so it is sane to expect both PDFs and PostScript (including EPS) files to be rasterized at that resolution by default. If you really want the double-size behavior, then the DPI should be saved as 144 dpi instead.
2. Allow the PS-to-PDF converter to accept a resolution in its PS input.

On 2006-04-07 at 01:48 PDT, I added the following information:

Oops. I meant to change the Steps to Reproduce but forgot. Here are the correct steps:

1. Open an Encapsulated PostScript (.eps) file containing an explicit resolution in Preview.
2. Save as PNG or TIFF.
3. Choose “Get Info” from Preview’s Tools menu, or press ⌘I.

1. I’m assuming that Simone Manganelli is a he. If not, sorry; no offense intended. ↶

Technorati tags: Apple Bug Friday, applebugfriday, PostScript.

This bug is iTMS: “Isms” is actually “Talisman”. It was submitted on 2006-03-31 at 23:59 PST.

Summary:

iTMS sells two albums by Divinorum. But these two albums are actually both the same one.

Steps to Reproduce:

1. Buy “Isms” from iTMS.
2. Listen to all of the tracks.

Expected Results:

You hear “Isms”.

Actual Results:

You hear “Talisman”.

Regression:

As far as I known, “Isms” has always been wrong. I submitted feedback when I bought “Isms” from iTMS in 2005-06. It’s still wrong.

Notes:

Bjorn Lynne distributes a number of his tracks for free, including two Divinorum tracks. One is “Antigravity”, the first track of “Isms”.

Listening to the iTMS previews of “Isms” and “Talisman” makes clear that they are the same. Listen to both “Antigravity” (track 1 of “Isms”) and “The Human Male” (track 1 of “Talisman”), for example.

Another demonstration is the track times. The “Antigravity” MP3 that Lynne distributes for free is 8 minutes and 14 seconds long. The version on iTMS is 7 minutes and 6 seconds long — the same length as “The Human Male”. All of the track lengths are the same between the two albums, except for track 11 (“Talisman” has 11 tracks; “Isms” has only 10 tracks).

Technorati tags: Apple Bug Friday, applebugfriday.

This feature request is iTunes should offer menu items to sort the selection. It was filed on 2006-03-31 at 23:35 PST.

Summary:

iTunes should allow [the user to specify — oops! —the Bored Zo] the order in which playlist items are stored in the playlist.

Steps to Reproduce:

1. Right-click on a selection, or click in the Edit menu.
2. In the ‘Sort by’ submenu, choose one of the criteria listed.

Expected Results:

The selected items are repositioned within the playlist (that is, the order in which they are stored changes).

Actual Results:

No results, because no such submenu exists.

Regression:

None known.

Notes:

iTunes does currently allow the user to change the order in which items are displayed by clicking a column header. But it offers no quick and easy way to sort items within the playlist itself (that is, to change the order in which the items are stored).

When a display sort (one of the column headers besides the far-left one) is selected, iTunes could run a dialog box: “The order in which the selected items are stored in the playlist was changed. The order in which they are displayed and will be played has not changed, because you have a different sort (^0) selected for display (in the column headers).” (^0 = name of selected column).

At 23:45, I added the following information:

Summary should read: iTunes should allow +the user to specify+ the order in which playlist items are stored in the playlist.

I had edited it and didn’t notice that I removed that part. Sorry.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is Terminal leaves files open when invoking shell directly. It was filed on 2006-03-24 at 23:45 PST.

UPDATE 2006-03-25: Uploaded the test app to GeoCities. Linked below.

UPDATE 2006-08-27: By GeoCities, I now mean boredzo.org. Link updated.

Summary:

When Terminal invokes a specific shell directly, rather than by invoking /usr/bin/login, several files are left open.

Steps to Reproduce:

1. Launch Terminal.
2. Terminal menu→Preferences….
3. Select “Execute this command (specify complete path):”
4. Specify the complete path.
5. File menu→New Shell.
6. Run the attached test app, or run ps and then run lsof with the pid of the shell.

Expected Results:

The test app prints “3”. lsof reports only three file descriptors: 0, 1, and 2, the respective FDs of stdin, stdout, and stderr.

Actual Results:

The test app prints “10”, “11”, “14”, or some other number. lsof reports a lot of open files having to do with Carbon (suggesting that the shell probably did not open them itself).

Regression:

None known.

Notes:

The test program creates and opens a file, and reports the FD it gets back from open. open returns the first FD that was available. In the absence of any other open files, this should be 3 (because that’s the FD after stdin, stdout, and stderr).

When I tested using test-app-free version of the above steps, I did observe that zsh 4.3.1 leaves open one file of its own (the terminal device). Perhaps it opens /dev/tty. This open file is not passed onto subprocesses, however, as is demonstrated by the test app.

Terminal (or Carbon) is responsible for all the other files that Terminal leaves open; this is obvious from the paths of the open files. Maybe login is closing them; in this case, Terminal should do this itself when the user chooses to bypass login.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is Symbols listed in File Manager Reference, not defined in header. It was filed on 2006-03-24 at 23:00 PST.

Summary:

The File Manager Reference contains 394 symbols that are not actually defined in any current header.

Steps to Reproduce:

1. Open the File Manager Reference.
2. Scroll.
3. Scroll.
4. Scroll.
5. Scroll.

Expected Results:

No signature and file-type constants are ever encountered, because no such constants are defined in the headers.

Actual Results:

You eventually arrive at 394 file type and signature constants, listed in eight sections in the Constants section.

Regression:

This wasn’t a problem back when these constants were actually defined.

Notes:

I constructed a header file from the header excerpts shown in the docs. It is attached.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is IPA support in Speech Synthesis Manager. It was filed on 2006-03-24 at 00:36 PST.

Summary:

Speech Synthesis Manager does not support IPA (International Phonetic Alphabet).

Steps to Reproduce:

1. Call a function such as CreateIPAStringFromString, which converts natural-language text into IPA.
2. Call a function such as SpeakIPAString, which speaks the text represented in IPA aloud.

Expected Results:

CreateIPAStringFromString returns a CFString containing the IPA version of the text.

SpeakIPAString parses the IPA text in the CFString passed in, and speaks it.

Actual Results:

The program fails to compile because Speech Synthesis Manager has no such functions.

Regression:

None known.

Notes:

IPA is a standard alphabet for representing pronunciation. It has its own block in Unicode, making CFString a natural fit. Thus, this report extends #4489914, “Speech Managers do not support Unicode” [see Apple bug Friday! 12 —the Bored Zo].

IPA used in this context would be a substitute for the phoneme syntax currently used in Speech Synthesis Manager (specifically, TextToPhonemes and SpeakBuffer).

At 04:11, I added the following:

I should clarify that I simply made up the names CreateIPAStringFromString and SpeakIPAString. I am not under a belief that those functions are supposed to already exist. I’m requesting functions that do those things, whatever they end up named.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is Speech Managers do not support Unicode. It was filed on 2006-03-23 at 23:07 PST.

Summary:

Neither the Speech Synthesis Manager nor the Speech Recognition Manager has support for Unicode text (CFStrings).

Steps to Reproduce:

1. Attempt to speak Unicode text using Speech Synthesis Manager.
2. Attempt to receive Unicode text from the Speech Recognition Manager.

Expected Results:

The Unicode text is successfully spoken, and speech from the user is successfully received as Unicode text.

Actual Results:

No results, because it is impossible to write such an application. Neither Manager supports Unicode.

Regression:

None known.

Notes:

Since Mac OS X now has CFStrings, the Speech Managers should at the very least support using these for input and output, even if actual parsing and recognition are limited to ASCII or MacRoman.

This could be extended in a future version of Mac OS X, with better support for other languages and accents using a broader range of the Unicode character set. Hard, I know — it would be a major feature, not a relatively-minor API enhancement like simply supporting CFStrings. CFString support is simply a first step in that direction.

Technorati tags: Apple Bug Friday, applebugfriday, Unicode.

I got a follow-up to Report-an-Apple-Bug-Friday! 8. I’ve HTMLized it, but otherwise it is unchanged.

This is a follow-up to Bug ID# 4481916. We have received the following update regarding your report:

Ray SAMPSON:

Engineering has determined this issue behaves as intended based on the following information:

Please know, EV_EOF is not to be set for just reaching the current end of a regular file. Otherwise, you could never wait for more data to arrive.

The flag indicates that no more data will ever be present to read – as when the sending end of a socket is closed. The closest thing for a regular file is when the containing filesystem is force-unmounted (which is when EV_EOF will be set for a regular file).

I’m satisfied. I put the following comment on the bug:

I suggest that this information be added to the manpage for kqueue, that EV_EOF does not get returned for a regular file unless the device containing the file disappears (along with any other circumstances that would cause that).

Thanks for the information.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is -[NSMenu menuBarHeight] always returns 0.0f. It was filed on 2006-03-17 at 23:55.

UPDATE 2006-03-25: Uploaded test app to GeoCities.

Summary:

NSMenu‘s -menuBarHeight method always returns 0.0f. Even the main menu’s.

Steps to Reproduce:

1. Call [[NSApp mainMenu] menuBarHeight].

Expected Results:

The method returns 22.0f.

Actual Results:

The method returns 0.0f.

Regression:

None known.

Notes:

Appearance Manager (in the form of the GetThemeMenuBarHeight function) and NSMenuView (in its +menuBarHeight method) both return 22.0f, the correct height of the menu bar under Tiger.

The documentation for +[NSMenuView menuBarHeight] recommends using -[NSMenu menuBarHeight] instead.

This method is superseded in Mac OS X v10.4 by the NSMenu menuBarHeight instance method.

Following this advice would break one’s app on 10.4.3 through 10.4.5 (the bug exists on 10.4.5 as well).

The bug works with any menu — the main menu isn’t the only one. It’s just the most obvious menu to call that method on.

Workarounds:

Use GetThemeMenuBarHeight or +[NSMenuView menuBarHeight].

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is iTunes should have a “Free Downloads” section on other front pages. It was filed on 2006-03-17 at 21:19.

Summary:

iTunes Video Store front pages don’t have a “Free Downloads” section like the Music Store’s does.

Steps to Reproduce:

1. Launch iTunes.
2. If the Music Store source is not already selected, select it.
3. Click on Movie Trailers, Music Videos, or TV Shows.
4. Click on the background inside the Music Store view (to the right of the source list).
5. Hit End.

Expected Results:

You see a “Free Downloads” section in the bottom-left corner.

Actual Results:

You don’t see a “Free Downloads” section in the bottom-left corner.

Regression:

None known.

Notes:

The Video Store (especially the TV Shows section) has had a number of free downloads lately, such as the free pilot and feelies for Conviction and the free “This is SportsCenter” commercials. There is no centralized place on any Video Store front pages where people can easily find these free downloads. One must look at all the values for the rotating poster views at the top of the page, and the non-rotating poster views in the middle of the page (below the first middle row).

And yes, this feature request does go toward making it easier for me to compile the “Free Stuff on iTunes” posts. ;)

Technorati tags: Apple Bug Friday, applebugfriday, iTunes, iTunes Music Store, iTMS, iTunes Video Store, iTVS.

This bug is Terminal should support xterm‘s 256-color mode. It was filed on 2006-03-17 at 20:44.

Summary:

xterm has a 256-color mode. Terminal should support it.

Steps to Reproduce:

1. Launch Terminal.
2. Run 256colors2.pl from the above website.

Expected Results:

Lots of pretty colors.

Actual Results:

Lots of backslashes and 16 pretty colors.

Regression:

None known.

Notes:

Some applications, including vim, look for TERM to be set to xterm-256color. Therefore, Terminal’s default should be changed to this if 256-color support is added.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is kevent does not return EV_EOF when an open regular file reaches EOF. It was filed on 2006-03-17 at 02:27.

Summary:

EVFILT_READ on a regular file never returns an event with the EV_EOF flag set.

Steps to Reproduce:

1. Create a kqueue.
2. Open a file for reading.
3. Add a kevent description to the queue from step 1 with EVFILT_READ and the fd from step 2.
4. Read until the end of file.
5. Call kevent.

Expected Results:

The data member of the returned kevent structure has the EV_EOF bit set.

Actual Results:

The data member of the returned kevent structure never has the EV_EOF bit set, so if your app is expecting it, it keeps on polling forever and never closes the file.

Regression:

None known.

Notes:

I also tried calling read and kevent one more time (testing for feof behavior), but still did not get EV_EOF.

A test case is included.

(Note: GeoCities is being cranky today. The test case will be up eventually.)

Technorati tags: Apple Bug Friday, applebugfriday.

So much for filing these earlier in the week. I spent the whole week pounding on the test cases.

This bug is kevent read events’ .data is random when st_size > ULONG_MAX. It was filed on 2006-03-17 at 01:55.

Summary:

When the size of a regular file exceeds ULONG_MAX, the value of the event’s data member can be truncated.

Steps to Reproduce:

1. Create a kqueue.
2. Open a file for reading.
3. Add a kevent description to the queue from step 1 with EVFILT_READ and the fd from step 2.
4. Poll the queue for events.

Expected Results:

The data member of the returned kevent structure, indicating the amount of data between the file’s current position and the end of file, is capped to ULONG_MAX to work around truncation issues.

Actual Results:

The data member of the returned kevent structure, indicating the naked size of the file, may be truncated or appear negative.

Regression:

None known.

Notes:

The st_size member of struct stat is an off_t (a long long), which is 8 bytes. The data member of struct kevent is an intptr_t (a long), which is 4 bytes.

kevent appears to simply assign the .st_size value directly to event.data in all read events. This produces the exhibited effect: only the low 4 bytes are copied; the high 4 bytes are thrown away. If the .st_size value exceeds ULONG_MAX, then the resulting 4-byte value would appear random if you didn’t know what was going on.

The other problem is that, unless I’m wrong about what a ‘vnode’ is, this behavior does not match the manpage’s description:

EVFILT_READ

Takes a file descriptor as the identifier, and returns whenever there is data available to read. The behavior of the filter is slightly different depending on the descriptor type.

⋮

Vnodes

Returns when the file pointer is not at the end of file. data contains the offset from current position to end of file, and may be negative.

.data only contains the offset to the end of file when the open file’s position is at the start of the file, since at that time, that value is equal to the length of the file.

.data should always contain the offset, unless that value exceeds ULONG_MAX, in which case it should be ULONG_MAX (that is to say, .data should be capped to ULONG_MAX).

Workarounds:

• Don’t use kevent.
• Ignore event.data and only use results from fstat/read/fread.
• Use mmap.

A test case is included.

(Note: GeoCities is being cranky today. The test case will be up eventually.)

UPDATE 2007-08-02: I’ve updated the test case to fix a bug. Here’s kevent-read-bug r2.

Technorati tags: Apple Bug Friday, applebugfriday

I’ve developed quite a backlog of bugs and feature requests to file. so I’m going to do ABF differently, at least for awhile.

You’re used to seeing my ABF posts titled “Report-an-Apple-bug Friday! N” (for N = 1–∞). Henceforth, a post so titled means that the bug was filed with Apple that day (which is consistent with all my ABFs so far). But, starting today, I’ll also file bugs on days other than Friday, so as to whittle down my backlog and give Apple that much extra lead time to fix these. Blog posts for such bug reports will be titled “Apple Bug Friday! N”. This tells you that the bug was filed previously, and is only now being blogged because today is a Friday.

The “Apple bug Friday!” posts will come at a rate of one per week, except when two or more bugs are similar (for example, I have a couple of kevent bugs to report that will be doubled up on next Friday). And if I find a new bug, and it happens to be on a Friday, I’ll do another “Report-an-Apple-bug Friday!” post.

part two of a two-fer. I did this one with proper capitals because the last paragraph was pretty long and I couldn’t think of a good way to break it up. the capitals were my second-choice clean-up method.

this bug is iTunes provides no UI for downloading a new episode on a multi-pass.

UPDATE 2006-03-11: Simone Manganelli mentioned in the comments that I failed to mention that you can Check for Purchases to get new updates (see Multi-pass implementation sucks). everything he said there is correct. mea culpa. :)

I also noticed when I went to edit this that I did not link to the bug report. oops. fixed.

UPDATE 2006-03-14: somebody has put “ITMS: ” in front of the bug’s title.

Summary:

iTunes needs to provide explicit UI for downloading new episodes of The Daily Show or The Colbert Report.

Steps to Reproduce:

1. Receive the email notification that a new episode is available.
2. Launch iTunes.

Expected Results:

one or more of:

1. iTunes presents a dialog box that you have episodes waiting to be downloaded, offering to add them to your shopping cart if that is enabled, offering to download them immediately otherwise.
2. iTunes presents a Growl notification that you have episodes waiting to be downloaded. (OK, so I wasn’t expecting it, but it would be nice. :)
3. The iTunes Music Store offers a section listing episodes you haven’t downloaded yet. Perhaps on the Account Information page, being that the notification email tells you to “sign in”. If you try to do this while already signed in, you go to the Account Information page.

Actual Results:

You must sign out and then sign in again to receive the new episode(s).

Regression:

None known.

Notes:

At the very least, the email should point out that you must sign out before signing in if you are already signed in (because signing in does work when you are already signed in, and it has a different result that doesn’t include checking for new multi-pass episodes).

Even better would be a clearer, more explicit UI for checking for and downloading multi-pass episodes. Such UI should include the shopping cart if it is turned on. Though a multi-pass is similar in operation to a podcast, it is not present in the Podcasts source at all; it is, instead, in the Music Store, so multi-pass downloads should behave as any other Music Store download, i.e. go through the shopping cart.

Technorati tags: Apple Bug Friday, applebugfriday.

part one of a two-fer.

this bug is The Daily Show and The Colbert Report not listed among iTunes TV Shows.

UPDATE 2006-03-11: forgot to link to the bug report. oops. fixed.

Summary:

in iTunes’ Browse view, The Daily Show and The Colbert Report are not listed.

Steps to Reproduce:

1. click on Music Store. you do not need to load the front page; if you don’t want to, click .
2. click Browse.
3. click TV Shows.

Expected Results:

The Daily Show is listed between Conviction and Desperate Housewives. The Colbert Report is listed between The Biggest Loser and Comedy Central Stand-Up.

Actual Results:

neither The Daily Show nor The Colbert Report is anywhere in the list.

Regression:

none known.

Notes:

rdar://4407769 is a previous instance of missing TV shows.

Technorati tags: Apple Bug Friday, applebugfriday.

I couldn’t remember on Friday what it was that I wanted to report. I finally remembered the Saturday afternoon after. so once again, I’m posting it late and forging the date. No rhyme intended.

This bug is TIFF files not supported as bundle icons, an enhancement request. As usual, I did not modify it for the open web except to HTMLize.

Summary:

Mac OS X only accepts IconFamily (icns) files as bundle (e.g. application) icons. Mac OS X should also accept TIFF files, which are more flexible and arguably easier to create (depending on your Terminal-fu).

Steps to Reproduce:

1. Create a bundle.
2. Place a TIFF file named “Icon.tiff” in the Contents/Resources subdirectory of the bundle.
3. In Contents/Info.plist, set CFBundleIconFile to either “Icon.tiff” or “Icon”.

Expected Results:

Mac OS X, upon noticing the bundle, recognizes the TIFF file as the bundle’s icon. Finder uses as the bundle’s icon the image from the TIFF whose dimensions most closely match the target icon size defined in View Options.

Actual Results:

The bundle has a generic bundle or application icon.

Regression:

None known.

Notes:

A TIFF file can hold one or more images of any size. TIFF files containing more than one image can be created with the third-party tiffcp utility, or Apple’s tiffutil -cat that is based on tiffcp.

An IconFamily file is limited to five resolutions: 16-pt, 32-pt, 48-pt, 128-pt, and 256-pt. Also, the 256-pt resolution cannot be created with any current software. It is theoretically supported by the operating system, but no current application can create an IconFamily containing a 256-pt image — not even Icon Composer. tiffutil/tiffcp can and will easily add a 256-pt image to a TIFF file, or any other size image.

Besides the obvious MIP-mapping advantages, TIFF also supports compression. Images in a TIFF file can be compressed with JPEG, LZW, or PackBits, among other codecs. IconFamily does not support any compression. So given a TIFF file and an IconFamily file with the same set of images, the TIFF file would likely be smaller with the advantage of compression. This would also help ameliorate the disk-space hit of adding 256-pt images to some bundle icons.

UPDATE 2006-08-27: This was written before I found out that the 256-px images are compressed when they are stored into an IconFamily structure/file, and decompressed upon retrieval.

fie on Blogger. this post isn’t visible from the front page or the Dashboard, even though it exists. so I’m reposting it.

UPDATE 2006-02-25: it has been closed as a duplicate.

C99 escapes in Obj-C string contain UTF-8 interpreted as an 8-bit encoding. as last time, edited only for HTMLification.

Summary:

since C99, C has a \u escape for Unicode characters. for example, a snowman is \u2603.

when used in an Obj-C string literal (@"foo"), however, these escapes are broken.

Steps to Reproduce:

1. write a program that displays a string, created from an Obj-C string literal containing a Unicode escape.
2. compile it.
3. run it.
4. observe the display of the string.

Expected Results:

the Unicode character is displayed as such.

Actual Results:

the Unicode character’s UTF-8 representation is displayed in some 8-bit encoding (possibly ISO 8859-1).

Regression:

none known.

Notes:

the bug only occurs in Obj-C string literals, not plain C string literals.

it appears that the compiler uses UTF-8 for internal storage, which works. NSConstantString, however, seems to expect ISO 8859-1, and interpret its input as such.

the enclosed tarball contains test programs (command-line) in plain C (using printf) and Obj-C (using NSLog). the plain C version works; the Obj-C does not.

I found the bug when displaying an Obj-C constant string (which had been passed through NSLocalizedString, but there is no matching localisation for it yet) as an NSMenuItem‘s title. so the problem is not specific to terminals or Terminal’s display, nor dependent on the value of any locale environment variables.

I also attached two test cases.

I submitted a new bug: NSFileManager does not accept NSString values for HFS types. it follows, edited only for HTMLification.

Summary:

from the NSFileManager documentation:

The following keys access file attribute values contained in NSDictionary objects used by changeFileAttributes:atPath:, fileAttributesAtPath:traverseLink:, createDirectoryAtPath:attributes:, and createFileAtPath:contents:attributes::

⋮

NSFileHFSCreatorCode

NSNumber containing an unsigned long (see “HFS File Types”)

NSFileHFSTypeCode

NSNumber containing an unsigned long (see “HFS File Types”)

⋮

Steps to Reproduce:

/*1*/ NSDictionary *attrs = [NSDictionary dictionaryWithObjectsAndKeys:
  NSFileTypeForHFSTypeCode('FOO!'), NSFileHFSTypeCode,
  NSFileTypeForHFSTypeCode('BAR!'), NSFileHFSCreatorCode,
  nil];
/*2*/ [[NSFileManager defaultManager] createFileAtPath:@"strings are our friends.txt"
                                         contents:[NSData data]
                                       attributes:attrs];

Expected Results:

the file is successfully created and imbued with both of the desired attributes.

Actual Results:

NSString throws an exception because it does not respond to -unsignedLong (yes, I know I got this selector wrong when I filed it — oops —ed), as assumed by NSFileManager.

Regression:

none known.

Notes:

NSFileTypeForHFSTypeCode appears to be the canonical way to create, effectively, an ‘instance’ of an HFS file type to be passed around in Cocoa, but NSFileManager only accepts NSNumbers. NSNumber seems to me to be more of a ‘raw’ representation. besides which, this usage of it definitely assumes the length of an unsigned long.

my first ever. yay!

in iTunes, there is a ‘Browse’ display, activated by clicking a ‘Browse’ button in the upper-right corner of the ⌘1 window. this provides a hierarchical display of the contents of the currently-selected source. in the iTunes Music Store, one of the top-level selections is ‘TV Shows’.

you would expect that selecting ‘TV Shows’ here would show you a list of all the TV shows available to be bought on the iTunes Video Store. and you would be wrong, because it only lists some of them.

the full list of displayed shows is:

• Adam 12
• Alfred Hitchcock Presents
• Battlestar Galactica
• Commander in Chief
• Desperate Housewives
• Dragnet
• Knight Rider
• Law & Order
• Lost
• Monk
• Night Stalker
• The Office
• The Suite Life of Zack & Cody
• Surface
• The Tonight Show with Jay Leno

this leaves out a number of shows, including well-known ones like Late Night with Conan O’Brien and Saturday Night Live.

filed as rdar://4407769.

UPDATE 2006-01-30: it seems fixed now, although the bug isn’t closed yet.