Off-topic MacOS resource flaming, was : Re: checking out mac resource forks, file checkout order

[Nico Kadel-Garcia <nk...@comcast.net>]

[ 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

Re: Off-topic MacOS resource flaming, was : Re: checking out mac resource forks, file checkout order

[Evert | Collab <ev...@collab.nl>]

Nico Kadel-Garcia wrote:
>
>
> 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.
>
Lots of files are stored in multiple blocks on a disk..

The difference between windows and (old) mac resources:

* windows stores the resource data at the end of a file
* mac stores it in a separate file

* to get the resource information in windows, you would have to seek to 
that point
* in mac, you could open the resource file

In the case of obtaining the data, mac wins, because:

in the inode table (well thats how its called with ext2/3, im sure 
hfs/fat/ntfs have different names for that) only the first location is 
stored per file.. To find a certain spot in a file you would have to 
follow that location and obtain the location for the next block in that 
location. To find the resource information you would have to traverse 
through all the blocks (a seek operation)

For Mac, you can simply open the known location, also in most cases this 
table is cached, so it turns out to be _a lot_ faster..

However, this discussion is pretty pointless.. the reason the old mac 
resource forks are obsolete now is for a simple.. its inconvenient. 
Speed is not much of an issue.. most normal file operations completely 
ignore resources except in the UI.. (finder/explorer)

    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.

The kernel has nothing to do with this..

I'm happy to discuss it further, but lets take it off list from this 
point.. I'm sure most people agree..

Evert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org