On May 21, 2006, at 10:38 AM, Nico Kadel-Garcia wrote:
> Dave Camp wrote:
>
>> I agree that resource forks should be avoided these days, but your
>> assertions that they are unreliable or slow down the file system are
>> incorrect.
>
> It means that every single filesystem operation, such as read,
> write, delete, rename, or copy takes twice as m any operations:
> that means accessing the disk *twice* for a lot of very basic
> operations. That can and will slow down the most basic operations.
> Doubling the complexity of such a variety of operations also
> endangers the filesystem: with twice the number of operations, and
> those operations tightly cross-linked in such a way that screwing
> up either of them screws up the actual file desired, you're just
> begging for file system failures.
The blanket statement that it takes twice as many operations is
incorrect. Reading an arbitrary amount data is the same as it would
be on any filesystem. read() seeks to the correct place in the file
and reads the data. Same for write(). There is nothing special about
this on HFS+ or with files with resource forks.
Delete and rename are a single operation on HFS+. There is a single
entry in the catalog B*tree representing the first two forks of the
file. Delete and rename would be two operations on other filesystems
where the resource fork was stored as a separate file.
Copy is similar to delete in that you would deal with a single file
on HFS+ and two files on other filesystems. However, the amount of
data to be copied would be the same. That is, if a developer wrote
code to save all of his data in the data fork instead of putting some
it in the resource fork, the amount of data in the "file" is the
same. The only difference how it is contained. The amount of data
copied is the same in both cases
>> The only problem with file forks is that they are unique to HFS and
>> HFS+. There isn't a good way to represent them on other filesystems
>> and source code that isn't Mac specific doesn't know they exist.
>> Resource forks don't "double-up on file operations" as the data
>> contained in them would have had to have been copied using some other
>> method if resource forks had not been used (e.g. data in a separate
>> data file, data added to the main file, etc).
>
> Yes, but that data would be in *one file*. That means a single disk-
> access, not two.
No. With the (much needed) demise of resource forks, all of the
various bits of data that would have been stored in individual
resources in a single resource fork are now shot-gunned across
hundreds of individual files in a Bundle folder. It's not uncommon
for a single application to be composed of up to a hundred different
files (icons, UI layout, strings, etc). In the past, each one of
those files probably would have been a separate resource in the
resource fork.
> Much of the old resource data, such as associating programs with
> files, has since been changed to using three-letter suffixes for
> file types, and this seems to be enough.
You seem to be confusing metadata with resources. They are not the
same thing. Resource forks were typically used for storing needed
bits of data for a program, such as icons, UI layout data, strings
for each language, etc. Metadata, such as file creators, types,
dates, etc has always been stored in the catalog file itself, at
least on HFS. On other filesystems, this data was either lost or
saved in a separate file.
> Most of the resource data is, in fact, not used and useless to
> normal operations.
Again, you seem to have mixed up metadata and resources. Removed the
resources from most any app that uses resource forks and it will most
likely not work at all. Again, resources are a way of storing bits of
data the application needs, not just metadata.
Hope that clears things up a bit. Again, I'm not defending resource
forks, I agree that getting rid of them is the correct solution, just
not for the reasons you put forth.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 21 23:13:10 2006