Re: Deleting resource forks
Re: Deleting resource forks
- Subject: Re: Deleting resource forks
- From: Philip Aker <email@hidden>
- Date: Sun, 14 Jul 2002 06:18:02 -0700
On Friday, July 12, 2002, at 09:51 AM, garbanzito wrote:
After execution, the file had no resource fork because when I
tried to open it with ResEdit, I was asked if I wanted to
create one.
So what exactly do you mean when you say: "the name is deceptive"?
well, it's a semantic issue. when a fork has zero length, does
it exist? i took the documentation literally when it said a
resource fork "always exists" for HFS+. similarly if you have a
file with a zero length data fork, does that fork exist? the
way the documentation was worded seemed intended to clarify
that FSDeleteFork() didn't necessarily actually delete the fork.
I have received a reply from an Apple Engineer (Mark Day) and
his comments are quoted at the end of this message. I think you
will see from them that FSDeleteFork() _effectively_ deletes the
fork.
the ResEdit behavior isn't definitive, i think, because ResEdit
actually populates the resource fork with 286 bytes of data
when it offers to "create one". in ResEdit's limited domain, an
empty resource fork is not a resource fork.
No, the ResEdit behavior I described is correct. If you open up
a resource file and delete all the resources in it, then it
still has a resource map which is the 286 bytes you describe and
if you try to open it again with ResEdit you are not asked if
you want to create a resource fork for the file. If you use
FSDeleteFork() then all the resources plus the map are deleted
and ResEdit will ask you if you want to create a resource fork
for the file.
But now I can see why you would say that the name for
FSDeleteFork() is deceptive in that it doesn't truly reflect
what the function does. However, although I hadn't actually
tried the function when I first mentioned it, I just assumed
(from being somewhat familiar with Apple's naming conventions)
that it would perform as expected. For instance if you call
DisposeHandle() at some point in your code, the handle still
exists until the function it is contained in goes out of scope.
It will be invalid but it still exists. Likewise for resource
forks. They don't go "out of scope" until the file itself is
deleted.
*=*=*=*
On Friday, July 12, 2002, at 01:02 PM, Mark Day wrote:
Technically speaking, it really is just leaving a zero-length
fork (on HFS and HFS Plus) since you can't delete just a fork.
In the on-disk structures, there is a catalog record which
contains things like the type and creator, modification date,
etc. The catalog record also has a substructure for the data
fork and a substructure for the resource fork. Those
substructures are always there for every file, whether or not
the fork has anything in it. (When I see "delete the fork",
I'm equating that to "remove the substructure from the record",
which can't happen.) On HFS and HFS Plus, it is impossible to
distinguish between a fork that exists with zero length vs. a
fork that does not exist.
Is it that you were worried that the logical end-of-file would
be set to zero, but that the previously allocated space would
remain allocated, and the fork's physical size would be
non-zero? (That is, when you say "delete", you were thinking
of "deallocate"?) If that's what had you worried, could you
write a bug report and suggest better wording?
As a contrasting example, some volume formats (like UFS or DOS
FAT) don't have dedicated structure to keep track of a resource
fork. Carbon actually creates a separate (hidden) file to
store the resource fork. In this instance, FSDeleteFork may
actually delete that hidden file completely (as long as Carbon
wasn't storing something else, like Finder info, there).
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.