Report-an-Apple-bug Friday! #2

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.