why NTFS reports incorrect file sizes
D. Hugh Redelmeier
hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org
Fri Jan 20 06:41:57 UTC 2012
| From: Andrej Marjan <andrej-igvx78u1SeH3fQ9qLvQP4Q at public.gmane.org>
| OSX makes heavy use of extended attributes. See
| http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3 (the
| "Installation footprint" section) for some details. And resource forks have
| been re-purposed, per that same article.
Thanks.
The resource fork seems to have been used in an unimportant way. I
mean, if you have it, sure, use it like that, but the application does
not justify if.
The use appears to be: put a compressed object code file (what we used
to call a.out) in the resource fork rather than the data fork. The
data fork is left then empty.
Surely putting the compressed executable in the data fork, with a
distinct magic number, would work much better in a UNIX environment.
The traditional bag-of-bytes tools would still work (cp, tar, ...).
What would break?
The extended attributes appear to be useful. They are a continuation
of the legacy of older MacOS and would be expected by any Mac user.
The "type" and "creator" are much cleaner ways of determining which
application owns a data file than the hacky "file extension"
convention.
The concept of "ownership" is quite useful with the desktop metaphor
being so impoverished when it comes to verbs. You point at an
Excel spreadsheet file, say "ugh ugh" (the only intransitive verb other than
"ugh"), and the system knows you mean "run the creator (Excel) on this
file".
This metaphor maps fairly poorly onto the UNIX way. But we've done
it anyway. We imitated MS Windows which imitated MacOS which was
inspired by Lisa which was inspired by Bravo, which was inspired by
the Alto's system.
Anyway, I feel that
- resource forks are not a good feature for UNIX / Linux
- extended attributes are not a good feature for UNIX / Linux as far
as I know
Either feature could be good if widely adopted conventions for their
use appeared and that convention was worthwhile. That condition seems
to have been met by OS/2 and MacOS.
If resource forks were useful, I suspect that directories could be
used instead.
I've sometimes thought that directories and files could be unified
differently (but not in Unix). Each file-system object could have a
data fork and a directory fork. Then there would be only one kind of
node, not two. Symlinks? The work of the devil.
--
The Toronto Linux Users Group. Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
More information about the Legacy
mailing list