Re: Minor filesize differences between "info" inspector and NSFileManager on SOME files.
Re: Minor filesize differences between "info" inspector and NSFileManager on SOME files.
- Subject: Re: Minor filesize differences between "info" inspector and NSFileManager on SOME files.
- From: email@hidden
- Date: Mon, 13 May 2002 10:46:14 -0700
Charles Bennett wrote:
|I didn't know about the /rsrc option. Then again I'm a UNIX head
|so I never think of resource forks.. :-)
|
|Seems like there should be a bug report filed here.
|To be consistant NSFileManager, ls and FSGetCatalogInfo
|should at least agree.
The problem isn't that they don't agree on how large a file is. The problem is that they don't agree on *what* a file is, due to their different heritages. In the Unix view of the world (held by ls and [I think] NSFileManager), a file is a *single* sequence of bytes. To Carbon (and OS 9 and Finder), a file is a *collection* of sequences of bytes; each sequence is called a "fork". The difference in reported sizes arises because Unix checks only the data fork (which it thinks of as "a file") while Carbon and the Finder check all the forks.
The difference is so utterly fundamental to how Unix and Carbon apps work that it isn't ever going away. Making Carbon et al. adopt the Unix point of view would break all the Carbon apps, while making Unix adopt the Carbon point of view would break the Unix apps. The problem at the Unix end isn't so much the command-line tools as the underlying system calls. For example, given the basic (and incomplete) file-copying program
int n;
while((n=read(src, buffer, sizeof(buffer)))>0)
write(dest, buffer, n);
if the read() call is told to read a file with both data and resource forks, when should end-of-file be reported? At the end of the data fork? At the end of the resource fork? Should the data fork be read before the resource fork, or after? Should the program specify whether it wants both forks? Etc.
The problem is rooted in another Unix assumption: all files are unstructured, as far as the OS is concerned. Various *applications* may define a structure, but the OS itself doesn't. (There are exceptions, of course: executable files, disk images, and the like, but, in general, the OS assumes as little as it can about what's in a file.) Introducing forks introduces structure, at a level that the OS is *forced* to recognize. Further, the resource fork itself is structured, although most of the OS could probably ignore that structure.
The "solution" adopted by Apple is to make the resource fork generally invisible to Unix code, by defining the data fork as the Unix view of the file. This is because the data fork, by itself, is a very good approximation to a Unix file; the Carbon routines make no more assumptions about the contents of a data fork than the Unix routines make about the contents of a file. And, often, the data fork contains exactly what you want the Unix command to work with. (Text files, for instance, have the text in the data fork, with various non-text items in the resource fork.) Moreover, the resource fork often contains things that most Unix programs are better off *not* dealing with: custom icons, window positions, and other such Mac-only details. Better that a Unix app be protected from such matters.
The ".../rsrc" notation is basically a hack introduced by the HFS+ code to make the resource fork visible as a Unix-style file. It doesn't work on non-HFS+ file systems. Other file systems, UFS for example, represent the non-data forks differently.
Glen Fisher
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.