I'm in the process of moving one of my company's apps to a 64-bit environment, and thus do not have access to FSSpec functions any longer.
We have some data structures in our file format that saved off a vRefNum and dirID from the old FSSpec format into the file... In the past we were able to use carbon routines, going from FSSpec to FSRef and finally to CFURL, but the FSSpec routines are ont available at all in 64 bit, and even the FSRef ones are deprecated as of 10.9.
Internally we are using CFURL/NSURL but would still like to support conversion to and from these older file formats. Is there any way, using non-deprecated (or at least 64-bit friendly) routines I can get between a vRefNum and dirID to and from a CFURL?
Thanks much.
This is not supported by Apple, but you can use the volfs file system to do this, which is what Carbon does internally. See the following documentation from Apple:
http://developer.apple.com/legacy/library/qa/qa2001/qa1113.html
Here's a function that creates a CFURLRef from a volume ID and directory ID:
CFURLRef CreateURLFromVolumeIDandDirectoryID(dev_t volumeID, SInt32 directoryID)
{
CFStringRef thePath = CFStringCreateWithFormat(kCFAllocatorDefault, NULL,
CFSTR("/.vol/%d/%d"), volumeID, (int) directoryID);
CFURLRef theURL = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, thePath,
kCFURLPOSIXPathStyle, false);
CFRelease(thePath);
return theURL;
}
To use volfs, you would also need to convert your volume reference number to a volume ID. Here's one way to do that:
dev_t ConvertVolumeRefNumtoVolumeID(FSVolumeRefNum refNum)
{
FSRef root;
OSErr error = FSGetVolumeInfo(refNum, 0, NULL, kFSVolInfoNone, NULL, NULL, &root);
if(error != noErr)
return 0;
UInt8 path[500];
OSStatus status = FSRefMakePath(&root, path, 500);
if(status != noErr)
return 0;
struct stat volStats;
int err = stat((const char*)path, &volStats);
if(err != 0)
return 0;
return volStats.st_dev;
}
According to the linked documentation, apps should never do this, and this could stop working in any future version of OS X. But you asked...
In addition, volume reference numbers are not guaranteed to remain the same when a volume is unmounted and then remounted, so if you're writing them to disk, you have another problem.