Re: Why is NSString->FSRef so hard?
Re: Why is NSString->FSRef so hard?
- Subject: Re: Why is NSString->FSRef so hard?
- From: Charles Srstka <email@hidden>
- Date: Wed, 29 Apr 2009 23:02:15 -0500
On Apr 29, 2009, at 9:22 PM, Andrew Farmer wrote:
On 29 Apr 09, at 06:15, Mark Douma wrote:
If you are working with file paths, you shouldn't be using
componentsSeparatedByString:, nor should you be defining "/" to be
the component you should be separating by. What if someone had your
app inside of a folder they named "Apps/Utilities"? The HFS+
filesystem actually uses a colon as the path separator, so having
a / in the name of a file or folder is perfectly acceptable, but
would likely cause a headache and unexpected results if your code
were to encounter it. (Go to the Finder and try adding a /).
What you're saying here is incredibly misleading, and actively
harmful. While I believe that HFS+ uses ":" as a path separator on-
disk, virtually all non-Carbon userspace code makes use of UNIX
paths. Either Carbon or the Finder itself is swapping colons and
slashes for display purposes - running "ls" should reveal that
filenames which appear as slashes in the Finder appear as colons.
Indeed, the methods in NSPathUtilities are entirely equivalent to
string manipulation methods which split and join on slashes. They
handle a lot of special cases for you (absolute paths, for
instance), but they are in no way doing anything specific to HFS+.
Moreover, you can rely on the path separator remaining a slash for
the foreseeable future.
Carbon and the Finder are displaying the filenames as is, as HFS
allows slashes to be in a filename, and the colon is the separator.
Cocoa and the BSD layer, on the other hand, do swap the slashes and
colons. Presumably the idea is to display slashes in a filename as
whatever the path separator is supposed to be, so that the path can be
a standard UNIX path - my guess is that if you had a file on an NTFS
volume with a slash in its filename, Cocoa would interpret the slash
as a backslash. I don't have an NTFS disk to test that with, though.
With that said, I don't really see what is harmful about recommending
the use of NSString's path concatenation methods, which could save
quite a few headaches in the case that this *does* somehow change for
some bizarre reason, however unlikely that may be.
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden