[Dalgo]

I want to use Carbon for my file I/O because it looks like it's API's give me much more control over what I can do to the files, however there are some things about HFS+ that I don't understand. For example, I get the whole fork abstraction thing, but how can I tell how many forks a file has? Also, how can I read from an arbitrary offset in a file? Note I said file and not fork.

I don't know how I can treat a file as one big contiguous entity on an HFS+ volume and not as a collection of forks. It looks like the functions that deal with HFS volumes might work, but they all seem to warn that they will not work with files over 2 gigs on HFS or HFS+ volumes so I'm going to be stuck with using only HFS+ functions.

Is there anywhere that I can look to find more info on this and related topics?

Thanks for the help, in advance.

[Angus_D]

Originally posted by Dalgo:
<STRONG>I want to use Carbon for my file I/O because it looks like it's API's give me much more control over what I can do to the files, however there are some things about HFS+ that I don't understand. For example, I get the whole fork abstraction thing, but how can I tell how many forks a file has? Also, how can I read from an arbitrary offset in a file? Note I said file and not fork.

I don't know how I can treat a file as one big contiguous entity on an HFS+ volume and not as a collection of forks. It looks like the functions that deal with HFS volumes might work, but they all seem to warn that they will not work with files over 2 gigs on HFS or HFS+ volumes so I'm going to be stuck with using only HFS+ functions.</STRONG>

I would strongly advise against using resourceforks unless you need to read/write to them for legacy reasons. I'm not sure if you can get the number of forks in a file, I'm sure that in theory you can use others, but in practice the only ones that are ever used are the data fork and resource fork - I've never actually seen any others used, ever. I would seriously recommend you just use the data fork under OS X, otherwise you'll run into problems when files created by your app are manipulated using commandline tools (e.g. cp, mv) or are used on a UFS disk.

[Dalgo]

Okay, I guess that I just won't bother messing with extra forks. As of now, I don't know of anything that uses anything but the resource and data forks so I guess that it doesn't really matter.

Question: Apple's documentation on the Alias Manager seems to be lacking. I'm not quite sure hot to use the function:

OSErr FSResolveAliasFile (
FSRef *theRef,
Boolean resolveAliasChains,
Boolean *targetIsFolder,
Boolean *wasAliased
);

I want to use it to resolve something that I am not sure if is an alias or not. Actually, I don't really care if it was an alias, I just want the actual path:

err = FSResolveAliasFile (&data-&gt;file /*A pointer to an FSRef*/, true /*resolveAliasChains*/, &data-&gt;isFolder /*A boolean Variable*/, NULL /*Don't care if it wasn't actually an alias.*/);

but it always returns -50, which means that I passed it a bad parameter. I have no idea what I am doing wrong. Also, for no apparent reason, the FSGetCatalogInfo function crashes whenever I try to use it with a file. A backtrace, starting there, looks like:

#0 0x7026f884 in ConvertUTF8toUTF16 ()
#1 0x7026d248 in PBGetCatalogInfoSync ()
#2 0x7026d038 in FSGetCatalogInfo ()

Again, I have no idea what went wrong. I need to use Carbon functions for file I/O because the Cocoa API's aren't good enough. I have used Carbon function from within Cocoa before, so I doubt that the mixing of them is a problem, but the documentation for some Carbon stuff is worse than that for Cocoa so I am kind of stuck here. If anyone can help me here, I'd appreciate it.

[Angus_D]

isn't &struct-&gt;member the same as struct.member?

[iJed]

I don't think that HFS is really a truly multiforked file system. As far as I can remember it only supports the data and resource forks. Maybe HFS+ supports more...

[iJed]

double post

[ 06-17-2001: Message edited by: iJed ]

[Dalgo]

Originally posted by Angus_D:
<STRONG>isn't &struct-&gt;member the same as struct.member?</STRONG>

Data is a pointer to a strcuture of other structures. I needed to pass the address of one of the pointers to the structure that make up data. I'm not sure if I did that correctly, but data itself is a pointer, not a structure.

[ 06-17-2001: Message edited by: Dalgo ]

[Angus_D]

Originally posted by Dalgo:
<STRONG>

Data is a pointer to a strcuture of other structures. I needed to pass the address of one of the pointers to the structure that make up data. I'm not sure if I did that correctly, but data itself is a pointer, not a structure.

[ 06-17-2001: Message edited by: Dalgo ]</STRONG>

drop the &
you're getting the address of a pointer and then treating the pointer as if it was a struct, which isn't clever

[Dalgo]

Okay, I found out what the problem with FSResolveAliasFile was: the last parameter was not optional, so passing NULL was bad.

Actually, I wanted to pass the address of the pointer. It won't compile if I don't. It is supposed to (I think) put the resolved FSRef into the structure whose address I pass. I noticed that a lot of Carbon functions take the address of variables and put their results into them. Their only return value is an error value. Even where the functions don't modify the parameter, I think that passing the address is usually faster than passing the whole structure.

[Angus_D]

Originally posted by Dalgo:
<STRONG>Okay, I found out what the problem with FSResolveAliasFile was: the last parameter was not optional, so passing NULL was bad.

Actually, I wanted to pass the address of the pointer. It won't compile if I don't. It is supposed to (I think) put the resolved FSRef into the structure whose address I pass. I noticed that a lot of Carbon functions take the address of variables and put their results into them. Their only return value is an error value. Even where the functions don't modify the parameter, I think that passing the address is usually faster than passing the whole structure.</STRONG>

Hmm... Yes, I was aware of that. However, to me &struct-&gt;member looks like you're getting the address of struct, then using -&gt; to access member, whereas it looks like it gets the address of struct.member? [self setConfused:YES]

[Dalgo]

Well, you were right about the structure syntax with regards to FSGetCatalogInfo. I was passing a pointer to a pointer to a structure when I only wanted to pass a pointer to a structure. That seems to have been my problem. Thanks.