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.
Apple and their developers have worked hard to stabilize this stuff, and to
take advantage of its features that are why they used it in the first place,
but I've found it quite painful to support.
> A resource fork is essentially a database attached to a data file.
> They are two separate files that are managed as one by the
> filesystem. Actually, HFS+ supports an arbitrary number of forks on a
> file, not just two. However, I don't think Apple has used more than
> two historically.
True from my experience.
> 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. 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.
Most of the resource data is, in fact, not used and useless to normal
operations.
> In any event, the original poster should just move to data fork
> resource files. It will solve his issues with subversion and cause
> the least disruption to his code base.
I agree with this completely.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 21 19:40:45 2006