On Wed, Jun 18, 2008 at 5:07 PM, JongAm Park
<[EMAIL PROTECTED]> wrote:
> Thank you for the additional information.
>
> Interestingly I found a similar method in NSFileManager,
> fileSystemRepresentationWithPath.
> So, is there any document on which file system uses which representation?

"Filesystem representation" is a property of the OS, not of an
individual filesystem. It is not the representation of one filesystem,
but rather the representation used by the filesystem as a whole, as
opposed to pieces of the system unrelated to files.

The NSString and NSFileManager methods produce identical results as
far as I know, so use whichever one you like better.

> Also, is there any reason why a program, like the FCP, prefers the
> decomposed string over precomposed string?
> Will there be a problem, if a program expect decomposed string and its
> client program sends precomposed one to the server?
> (Well.. it depends on implementation of the programs.. )

A properly written program will accept any equivalent form of a string
as being the same as any other, unless it specifically says that it
requires a particular form. That said, many programs are buggy. The
Mac OS X kernel was a great example of this. Up to, I think, 10.2, the
kernel didn't properly convert all unicode sequences to the preferred
filesystem form, leading to buggy behavior if you gave it sequences it
didn't like. On more recent versions you can use any valid UTF-8 and
the kernel will convert it to the internal format that it requires.

In conclusion, you can probably send any form, but if you want to be
really careful, figure out what form the remote program "prefers" and
convert to that form before sending.

Mike
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to