[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Evert | Collab <evert_at_collab.nl>
Date: 2006-05-22 01:32:04 CEST

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
Received on Mon May 22 01:30:44 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.