• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why is NSString->FSRef so hard?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is NSString->FSRef so hard?


  • Subject: Re: Why is NSString->FSRef so hard?
  • From: Marcel Weiher <email@hidden>
  • Date: Thu, 30 Apr 2009 10:57:53 -0700


On 29.Apr, 2009, at 21:02 , Charles Srstka wrote:
On 29 Apr 09, at 06:15, Mark Douma wrote:

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.

Since all access to the filesystem is via the kernel and the kernel uses '/', the above is not true. Carbon and the Finder also get '/' from the kernel, they then proceed to swap them for legacy- compatibility. So what you are interpreting as "displaying the filename as is" is actually the result of two transformations that cancel each other out in that particular case.


Presumably the idea is to display slashes in a filename as whatever the path separator is supposed to be,

The display transformation is done by Carbon and the Finder. All kernel processing of paths is slash-based (except obviously inside one of the filesystems that do it differently, but that difference is not visible to the rest of the kernel or userland processes).


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.

It wouldn't be Cocoa doing this, it would be the kernel. So the kernel, BSD userspace and Cocoa would all see the slash. Carbon would translate the slash to a colon.


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.

Good advice, yes.

Marcel

_______________________________________________

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


References: 
 >Why is NSString->FSRef so hard? (From: Erg Consultant <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Nick Zitzmann <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Erg Consultant <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: "Stephen J. Butler" <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Erg Consultant <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Ken Thomases <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Erg Consultant <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Mark Douma <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Andrew Farmer <email@hidden>)
 >Re: Why is NSString->FSRef so hard? (From: Charles Srstka <email@hidden>)

  • Prev by Date: Re: #import errors and @class warnings
  • Next by Date: Re: NSURLConnection unhappiness
  • Previous by thread: Re: Why is NSString->FSRef so hard?
  • Next by thread: Re: Why is NSString->FSRef so hard?
  • Index(es):
    • Date
    • Thread