On 5/23/07 11:13 AM, "Dave" <email@hidden> wrote:
> Hi,
>
> I have decided to use the FSRef APIs, which begs another question,
> How do I convert a C string (or CFString) into an FSRef? My functions
> are passed a Posix File Path and I don't have a choice about that.
Here is my piece of code that does that:
(note that I store the data in an object that can hold an FSRef and a
unicode name because an FSRef can only point to an existing file and/or
folder, and the ScopedCFRef thingies is a simple class that will release the
CFObject when the object is deleted)
Frank
-----------------------------------------
if (inOSPath.size() == 0)
return;
bool isFolder = inOSPath[inOSPath.size() - 1] == '/';
ScopedCFRef< CFStringRef >
cfPath(CFStringCreateWithCString(kCFAllocatorDefault , inOSPath.c_str(),
kCFStringEncodingISOLatin1));
if (cfPath.Get() == NULL)
return;
ScopedCFRef< CFURLRef >
cfURL(CFURLCreateWithFileSystemPath(NULL,cfPath.Get(),kCFURLPOSIXPathStyle,i
sFolder));
if (cfURL.Get() == NULL)
return;
if (CFURLGetFSRef(cfURL.Get(), &mFSRef))
{
// existing file or folder. Check what it is
FSCatalogInfo catalogInfo;
OSErr osErr = FSGetCatalogInfo(&mFSRef, kFSCatInfoNodeFlags,
&catalogInfo, NULL, NULL, NULL);
if (osErr != noErr)
return;
if (catalogInfo.nodeFlags & kFSNodeIsDirectoryMask)
mSpecState = kFSRefIsAFolder;
else
mSpecState = kFSRefIsAFile;
MakeValid();
}
else
{
// non-existing file
ScopedCFRef< CFStringRef >
cfFileName(CFURLCopyLastPathComponent(cfURL.Get()));
ScopedCFRef< CFURLRef >
parentCFURL(CFURLCreateCopyDeletingLastPathComponent(NULL, cfURL.Get()));
if (parentCFURL.Get() == NULL)
return;
if (CFURLGetFSRef(parentCFURL.Get(), &mFSRef))
{
mSpecState = kFSRefAndFileNameAreAFile;
mFileName = CreateUserStringFromCFStringRef(cfFileName.Get());
MakeValid();
}
}
---------------------------------------
>
> Thanks a lot
> All the Best
> Dave
>
> On 22 May 2007, at 20:57, Rosyna wrote:
>
>> The other issue is that once you get start using paths (or any
>> technology), you tend to stick with them for all the code.
>>
>> Paths are extremely fragile and unfriendly to user, especially when
>> saving them in persistent storage.
>>
>> Since Mac OS X mounts volumes in /Volume/<vol name>/ it's very
>> possible for a path to become invalidated if it points to a file on
>> a volume that is not the boot volume. If for some unforeseen
>> reason, a folder with the name of the volume already exists in /
>> Volumes/ when it comes time to mount the volume, OS X will append a
>> number to that name, making the paths invalid.
>>
>> But everyone here already knew that.
>>
>> Also, since a path may span multiple volumes, there can be a
>> measurable amount I/O every time a path needs to be resolved to
>> it's real file. FSRefs don't have this issue.
>>
>> But everyone here already knew that.
>>
>> I guess it's best to just search the archives for "paths are evil"
>> before the reasons why paths are evil is rehashed again.
>>
>> Ack, at 5/22/07, Laurence Harris said:
>>
>>> The only real issue should be length.
>>
>> --
>>
>>
>> Sincerely,
>> Rosyna Keller
>> Technical Support/Carbon troll/Always needs a hug
>>
>> Unsanity: Unsane Tools for Insanely Great People
>>
>> It's either this, or imagining Phil Schiller in a thong.
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Carbon-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>> 40looktowindward.com
>>
>> This email sent to email@hidden
>
____________________F_r_a_n_k___V_y_n_c_k_e________________
Odystar
Graphics with Intelligence
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
