Re: what are .sdk archives?

In article <2KGcj.9924$yC6.6991@trndny05>,
"Charlie" <charlieDOTd@xxxxxxxxxxxxx> wrote:

"Gregory Weston" <uce@xxxxxxxxxx> wrote in message
news:uce-70F166.21323226122007@xxxxxxxxxxxxxxxxxxxxxxxxxxx

They serve the purpose of providing a mechanism to attach arbitrary
ancillary data streams to a directory entry without polluting the
primary stream, which may be a standard, commodity format.

I'm hard pressed to see that as a "useful" purpose.

And yet every major OS under active development today (as well as more
than a few defunct ones) ships with a recommended file system that
includes it.

I am aware that there are other file systems that allow resource forks and
operating systems that support them but I still feel that forked files are a
"solution in search of a problem".

The increased adoption of forks is a good indication that a problem
exists, given that the engineering effort to implement and support them
is not free and and benefit to paying users, when they exist, is not
really buzzword worthy. The problem, simply stated, is that there is
*sometimes* a benefit (or occasionally outright need) to associate
ancillary data with a file, the contents of which are in a commodity
data format that inherently disallows the attachment of that data or
makes it very difficult on a case-by-case basis. Have you, for example,
seen how much ID3v2 is complicated by trickery to allow it to pass
uninterpreted through a streaming renderer?


Although I'm not particularly knowledgeable on file systems and operating
systems I have noticed that although NTFS supports forked files, Windows (at
least through XP) uses them only for a few limited functions and even those
could easily be handled in a normal non-forked file.

There's more than one way to implement just about anything. If the task
is "attach arbitrary amounts and types of data to a single directory
entry" what superior solution do you propose?


The power comes not from being able to *write* the arbitrary streams of
information, but from being able to read them back again and do
interesting things like filtering. BeOS, for example, included a file
system interface that let the user define which of the arbitrary named
forks would show up in a list view. ...

The problem I have with this example and others that I've read in the past
is that all this can be done (and routinely is) by applications without
using forked files.

At the cost of greater development effort in each application and,
typically, reduced responsiveness. It sucks, but it sucks less than the
alternatives.


So long as a simple (unforked file) has a standard
format it is trivial for a program to read only the information it needs to
do things like filtering.

You're right. With a simple, well-structured format, extracting a single
piece of data is *usually* not objectively difficult. But the fact that
something isn't difficult doesn't mean it can't be made easier or that
there's no benefit to doing so. If it can be even easier (meaning less
opportunity for error and weird edge cases) and faster (meaning happier
users) isn't that a good thing? If I want to build a list of mail
senders' addresses on the fly, is opening every file and scanning for
"From: " and then reading to the end of the line and extracting the
address from whatever else is there - on the fly, remember - really a
better solution than looping on read_attr(f, "sender_addr")?


The benefit to the traditional Mac resource fork specifically was that
it provided a standardized method of modularizing application and data
files such that on a resource-starved machine you could load things on
demand instead of all at once. And, as noted earlier, you could augment
data files without actually compromising the structure of the data
stream.

And the same result can be (and is) achieved by placing the extended data on
a separate file.

That sentence suggests to me that you have misunderstood on a
fundamental level. Physically, forks *are* separate files. They're just
attached to the same directory entry to reduce clutter and reinforce the
association.

And if standardization is the goal then standard file
formats for the extended data seems to be the way to go since there is no
accidental loss of data when moving the files to other systems.

And for simple streams like text, or raw audio or pixel data?

<http://folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unifi
ed_Model.txt>

An interesting read. However, it doesn't convince me that forks really
solved anything. Adding a resource manager to a resource-starved machine so
that you can separate data kept in different forks seems counter productive.
Reading and writing forks requires more code in memory and adds a level of
complexity that is unnecessary.

I'm honestly not sure how you could have read that article and come away
with that impression. You seem, frankly, to be determined not to
understand, in which case there's little point in continuing to try.

G
.

Relevant Pages

  • Re: what are .sdk archives?
    ... I am aware that there are other file systems that allow resource forks ... systems I have noticed that although NTFS supports forked files, ... Putting the extra data in a separate file works well, ... And for simple streams like text, or raw audio or pixel data? ...
    (comp.sys.apple2)
  • Re: silent semantic changes with reiser4
    ... Once transporting streams becomes ... > information in a particular format that is common to one ... And any app that wants to search these ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: enumerating for available muxers and generic way of encoding video
    ... writer, yes, the Windows Format SDK does indeed mention ... how to configure it for pre-compressed streams. ... all inputs must be pre-compressed (the internal WMWriter ... the video format block must be a VIDEOINFOHEADER and the ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: silent semantic changes with reiser4
    ... Hence why I was suggesting the idea of disposable data in streams. ... > internal format, how to generate the index, and how to use it. ... By using lots of libraries, you end up using lots of memory to ... icon for the file to pull the appropriate icon from somewhere else (and ...
    (Linux-Kernel)
  • Re: back up ?
    ... "real" file in it) gets copied, any named streams stay behind. ... (Backup software is supposed to clear the bit ... directory entry in both systems, I know they are in the directory ... So I'd expect the settings of those flags to carry ...
    (microsoft.public.windows.vista.general)