Re: renaming a file with special/reserved characters in name
Re: renaming a file with special/reserved characters in name
- Subject: Re: renaming a file with special/reserved characters in name
- From: Michael Ash <email@hidden>
- Date: Wed, 25 Feb 2009 23:40:49 -0500
On Wed, Feb 25, 2009 at 7:47 PM, Martin Wierschin <email@hidden> wrote:
> Hello everyone,
>
> Forgive me if this has already been answered, but my searches through the
> archive didn't turn up anything.
>
> The situation is that I need to allow users to rename files within my
> application. The name of the file is displayed in an NSTableView, and the
> delegate method "tableView:setObjectValue:etc" triggers the underlying file
> to be renamed.
>
> A problem arises when a file contains special/reserved characters, eg: the
> dreaded backslash/colon. There's the handy -[NSFileManager
> displayNameAtPath:] which seems to convert colons in paths to backslashes
> for display, but no inverse. How am I to convert whatever name the user has
> entered to a form suitable for use with "stringByAppendingPathComponent:"?
>
> Likewise, what about validation? I don't believe a user can use a colon ":"
> on an HFS file system (at least my Finder doesn't allow it). I would expect
> a method on NSFileManager like "pathNameForDisplayName:" that returns nil if
> the name is illegal on the underlying file system. I hate to hardcode any of
> these characters.
There are only two characters which absolutely must be avoided in any pathname.
The first is the slash (/). Note, NOT a backslash (\), that one is
fine. Slash is the path separator and thus can't exist in a filename.
The second is the NUL character, which is unichar 0. Rarely a problem,
but it will confuse the API if you have it in your strings.
That's it. Everything else works.
Except it doesn't, because each filesystem is different. The above is
true for HFS+, it is NOT true for FAT32, which has a whole bunch of
other characters which are illegal.
This is the bad news: there is NO way to tell what those characters are.
Once you've eliminated the obviously bad ones, the only thing you can
really do is try it. If it fails, you might eliminate some more bad
ones, like the list of characters that FAT32 doesn't like. But that's
not guaranteed to be enough. You could be on a different filesystem
with a different list. You could be talking to a filesystem, like NFS,
where the list isn't constant.
Your best bet, once you strip slashes, is probably just to try it and
present the user with a friendly error telling him to use a different
name if it fails. It's painful to push the task of figuring out what
characters are illegal back onto the user, but it's the only realistic
way.
Mike
_______________________________________________
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