Re: what are .sdk archives?

["Charlie" <charlieDOTd@verEYEzon.net>]

"Gregory Weston" <uce@splook.com> wrote in message 
uce-4485BC.07365702012008@comcast.dca.giganews.com">news:uce-4485BC.07365702012008@comcast.dca.giganews.com...
> In article <eJDej.1274$nN5.76@trndny04>,
> "Charlie" <charlieDOTd@verEYEzon.net> wrote:
>
>> > But getting back to what I said above, that leads to either a
>> > potentially huge amount of user interaction or a lot of OS magic to
>> > maintain the relationship. To me it's very suboptimal for the user to
>> > see, in addition to their foo.txt file, an unbounded collection of 
>> > other
>> > files named foo.txt-xattr-SenderName, foo.txt-xattr-SenderAddr,
>> > foo.txt-xattr-Subject, etc. (It may not even be possible, given that we
>> > have to deal with limits on the lengths of both filenames and full 
>> > paths
>> > in most extant file systems today.) Just having them there buries 
>> > signal
>> > under noise. To then either require that the user rename the files, 
>> > copy
>> > them en masse or whatever *or* have the OS do so those manipulations
>> > implicitly just aggravates the situation.
>>
>> Suboptimal yes, but in my mind better than forks.
>
> Why, though? Why is it better for the user (and for that matter code
> traversing the file hierarchy) to have to wade through potentially
> hundreds of extra files they will never care about in order to find the
> single data file they actually want to manipulate in any given situation?
>

Why? Because of the problems with forks (portability to foreign systems, 
extra code needed to read and write forks, data hidden from user, etc.).

In the case of a system designed with an interface to use forks (as you 
mentioned with the Be system) the data would not be hidden from the user, 
solving that problem. If however, you designed a system around multiple 
unforked files so that the interface handled the "wading" through large 
amounts of files you eliminate the fork problems.

Charlie