Re: HSETFILEINFO Ques.
Posted by: rbrown <rbrown@...>
>
> There seems to be a difference in results using FN HSETFILEINFO vs FN
> SETFILEINFO. Mainly in the file's type and creator signatures. At the end
> of a file duplicating program, I wrap things up with a FN SETFILEINFO
> instruction and the duplicated file is created with correct signatures in
> the finder. But, if I substitute FN HSETFILEINFO instruction for the FN
> SETFILEINFO instruction the file is created ok but has no signatures
> recognized by the finder.
>
> Note: I took Rick Brown's advice and replaced GETFILEINFO instructions
> with HGETFILEINFO instructions because it's newer. Rick, however, didn't
> mention the HSETFILEINFO instruction, though. I just assumed....
FN HSETFILEINFO works just as well as FN SETFILEINFO, but requires a
little more care in setting it up. The difference between the
HGETFILEINFO/HSETFILEINFO pair and the GETFILEINFO/SETFILEINFO pair is
in one field of the parameter block: the ioDirID field.
This field is located in bytes 48 through 51 in the parameter block.
These bytes are ignored on input by GETFILEINFO and SETFILEINFO.
On the other hand, HGETFILEINFO and HSETFILEINFO require that this field
be set correctly. If you're specifying the file's folder as a working
directory reference number in the ioVRefNum field (and my guess is that
you were), then you need to set the ioDirID field to zero.
The catch is, that HGETFILEINFO _alters_ that field on output. It
sticks a little-used number called the "File ID" into bytes 48 - 51,
thus wiping out whatever ioDirID value you put there before. That means
you have to _reset_ those four bytes (to zero, or to a valid directory
ID) before you call HSETFILEINFO, assuming you intend to use the same
parameter block that you used in HGETFILEINFO. If you fail to reset
bytes 48-51, then HSETFILEINFO will take the File ID that was returned
by HGETFILEINFO, and incorrectly interpret it as an ioDirID number. It
will attempt (and probably fail) to find a directory that has that
directory ID number.
My guess is that this is what happened in your case. When you called
HGETFILEINFO, bytes 48-51 probably contained zero; when you called
HSETFILEINFO, those bytes probably contained a File ID number, which
HSETFILEINFO took as a directory ID. My guess is that it wasn't just
the file's type & creator signature that failed to get set; if you look
at the result code that HSETFILEINFO returned, I'll bet the entire call
failed, with something like a "directory not found" error. The reason
it worked when you swapped out HSETFILEINFO for SETFILEINFO was because
SETFILEINFO ignores the contents of those 4 bytes.
If you put HSETFILEINFO back in there, and make sure that you reset the
ioDirID field just before you call it, my guess is that it will work.
- Rick