Re: Resource Fork - is this a good use/the right thing to do?
Re: Resource Fork - is this a good use/the right thing to do?
- Subject: Re: Resource Fork - is this a good use/the right thing to do?
- From: Dmitry Markman <email@hidden>
- Date: Thu, 24 Apr 2008 00:17:48 -0400
I'm not sure what is all about
all resources can be stored in the data fork
resource manager perfectly understands it
there is no reason whatsoever to use resource fork.
you can easiliy convert old resource file (with resources in the
resource fork)
to resource file with resources in the data fork
Resorcerer, for example does it
you can write small application that will do that too
look, for example at the following code, that copies data fork of the
file specFile (resFork = false)
or copies resource fork of the file specFile (resFork = true)
to the normal data fork file.
copied resource fork will be perfectly usable in Xcode
Resorcerer will open it as well
OSErr CopyFork(FSRefPtr specFile, bool resFork) {
OSErr err = noErr;
HFSUniStr255 dataForkName;
err = FSGetDataForkName(&dataForkName);
if(err != noErr) return err;
HFSUniStr255 resForkName;
err = FSGetResourceForkName(&resForkName);
if(err != noErr) return err;
SInt16 fileFork = -1;
HFSUniStr255 fileName;
FSRef parentRef;
err = FSGetCatalogInfo(specFile, kFSCatInfoNone, NULL, &fileName,
NULL, &parentRef);
if(err != noErr) return err;
CFStringRef newFileName = NULL;
CFStringRef cfFileName =
CFStringCreateWithCharacters(kCFAllocatorDefault, fileName.unicode,
fileName.length);//CFString.h
if(cfFileName != NULL) {
CFMutableArrayRef tempArr =
CFArrayCreateMutable(kCFAllocatorDefault, 2, &kCFTypeArrayCallBacks);
CFArrayAppendValue(tempArr, cfFileName);
CFArrayAppendValue(tempArr, (resFork) ? CFSTR("rsrc") :
CFSTR("data"));
newFileName =
CFStringCreateByCombiningStrings(kCFAllocatorDefault, tempArr,
CFSTR("."));
CFRelease(tempArr);
CFRelease(cfFileName);
}
if(newFileName == NULL) return coreFoundationUnknownErr;
err = FSOpenFork(specFile,
(resFork) ? resForkName.length :
dataForkName.length,
(resFork) ? resForkName.unicode :
dataForkName.unicode,
fsRdPerm, &fileFork);
if(err == noErr) {
SInt16 outFile = -1;
FSRef newFSRef;
CFIndex length = CFStringGetLength(newFileName);
UniChar *buffer = new UniChar [length];
CFStringGetCharacters(newFileName, CFRangeMake(0, length),
buffer);
err = FSCreateFileUnicode(&parentRef, length, buffer,
kFSCatInfoNone, NULL,
&newFSRef,NULL);
if(err == dupFNErr) {
err = FSMakeFSRefUnicode(&parentRef, length, buffer,
kTextEncodingUnknown, &newFSRef);
}
delete [] buffer;
err = FSOpenFork(&newFSRef, dataForkName.length,
dataForkName.unicode, fsWrPerm, &outFile);
if(err == noErr) {
ByteCount actualCount = 0;
SInt64 positionOffset = 0;
ByteCount requestCount = 1024;
Byte *fileBuffer = new Byte [requestCount];
while(err == noErr){
err = FSReadFork(fileFork,fsFromStart,
positionOffset, requestCount, fileBuffer, &actualCount);
if(actualCount < 1) break;
positionOffset += actualCount;
OSErr writeErr = FSWriteFork(outFile,fsAtMark,0,
actualCount, fileBuffer, NULL);
if(writeErr != noErr) err = writeErr;
}
delete [] fileBuffer;
FSCloseFork(outFile);
}
FSCloseFork(fileFork);
}
CFRelease(newFileName);
return err;
}
On Apr 23, 2008, at 11:55 PM, Daniel DeCovnick wrote:
The problem with that is, as I wrote in my first message, the real
data files aren't mine, and won't be opened by my app exclusively.
The data that I need to save ought to be invisible to the file's
owner.
Imagine, for example, that when working on a file in HexEdit, it
allowed you to highlight in different colors and annotate locations
in a file. Where would HexEdit save those annotations and locations
and colors of highlighted areas?
-Dan
On Apr 23, 2008, at 11:33 PM, Jason Stephenson wrote:
Chris Suter wrote:
Furthermore, it doesn't follow the file which was the original
design goal.
Going back to the original question, I personally think that the
best thing to do is to just create another file and educate the
user. Extended attributes and resource forks are all very nice but
most users don't understand what they are and they just don't
interoperate nicely with other systems.
My first thought on reading this thread is that it would be easiest
just to store the data in a zip-type archive file. You could then
have all the metadata/resource files included in an archive
subdirectory, and everything would transfer nicely across operating
systems. OpenOffice.org does this. All of the components of a
document are stored in a zipped archive that just happens to have
the .odt or .od-whatever extension.
Using an archive file format solves the issue of user education,
since it appears to be a single file to the user, gives the
programmer the option of including whatever arbitrary resources are
needed for this particular file, and also solves the issue of
operating system portability, since just about any OS in current
use can handle copying a binary file around.
Just my 2d....
Cheers,
Jason
_______________________________________________
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
_______________________________________________
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
Dmitry Markman
_______________________________________________
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