why NTFS reports incorrect file sizes

Andrej Marjan andrej-igvx78u1SeH3fQ9qLvQP4Q at public.gmane.org
Thu Jan 19 17:16:04 UTC 2012


On Thu, Jan 19, 2012 at 12:01 PM, D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org>wrote:

>
> What were they actually used for?
>
> As far as I know, there is no strong culture / convention for using
> this capability in Linux.  As far as I'm concerned, all it
> accomplishes is to break the "a file is a bucket of bytes" model of
> UNIX files.  So tar won't work as a backup, cp won't work to copy a
> file, etc -- many utilities are broken or need(ed) revision.
>
> Extended attributes surely don't matter in Linux since I've been able
> to ignore them up to now.
>
> The beauty of UNIX compared with its precursors was simplicity.  I
> moved to UNIX from IBM OS/360.  Files there had all kinds of
> attributes that optimized how I/O was performed but actually just made
> file I/O complicated.  Files had "record formats" (how file blocks
> were to be broken into records), block sizes, record sizes, printer
> control types, indices, and more.  UNIX had "just a bucket of bytes"
> (plus, I admit, modest, fixed, simple metadata).
>
> In MacOS (pre-OSX) the "resource fork" of each file was important and
> there were strong conventions on how it was used.  So much so that Resedit
> (the resource fork editor) was a very powerful tool for customization
> without needing access to source code or being a programmer.
>
> I don't know how OSX resolved its twin heritages.
>

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.

The same author has written quite a few similarly exhaustive reviews of
various versions of OSX over the years which make for interesting reading
for the casual observer/non-OSX user.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20120119/12fc6a0b/attachment.html>


More information about the Legacy mailing list