[ I'm about to flame seriously, and have marked this off-topic. ]
Dave Camp wrote:
> 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.
Take a look at thedata actually on the disk. It's in two files, it's in two
separate places on the disk. The kernel obscures this. It's not an
"arbitrary amount data". The kernel has to access the directory structure
(admittedly) to deal with things like the name of the file, the file itself,
and in the case of these MacOS file filesystems, the resource fork. The
resource fork is an extra operation *to the disk*: it's stored separately.
> 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.
The B*tree is a way of describing the location of the files: since there are
two different places the information is stored, that means two operations on
two different blocks or sets of blocks. Even for a single empty file.txt
file, that means extra and unnecessary data.
> 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
But it's two different blocks or sets of blocks on the disk! That means two
operations. (OK, I've been ignoring the directory structure ones). And
frankly, for most modern software, the information formerly stored by the
resource fork is not particularly useful. Oh, this program created the file?
Who cares! The system that created the data file may have nothing to do with
the system that receives it, which may have entirely different programs for
opening it.
>> 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.
That data is, in most cases, not necessary. Text files or .doc files? Who
cares if the program had a funky icon or UI! And don't get me started on
language data! Yech! What a source of madness and instability!
>> 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.
Most of those "resources" were only used in a few circumstances, a source of
endless failure modes and grief, in my experience cleaning up after their
corruption. They had their uses, but those uses were usually better
contained in the program itself. Icons with data files? Who the heck cares
what icon is tied ot a program or file? That is 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 22 00:59:49 2006