Something that folks should keep in mind is that as far as I have been
able to determine, Microsoft isn't actually planning on using streams
for anything. As near as I can tell it was added so that their SMB
servers could replace Appleshare servers more efficiently, but that's
really about it. I don't believe, for example, that MS Office 2000 is
going to be using the streams functionality at all, and this is for a
very good reason.
Streams really lose when you need to send them across the internet. How
do you send a multifork file across FTP? Or HTTP? What if you want to
put the multifork file on a diskette that's formatted with a FAT
filesystem for transport to another OS? What if you want to tar a
multifork file? Or use a system utility like /bin/cp or /usr/bin/mc
that doesn't know about multifork files?
One of the reasons why the Apple resource-fork was a really sucky idea
in practice was that executables stored dialog boxes, buttons, text, all
in resources --- which would get lost if you tried to ftp the file
unless you binhexed or otherwise prepped the file for transfer first.
So I question the whole practical utility of file streams in the first
place. The only place where they don't screw the user is if the
alternate streams are used to store non-critical information where it
doesn't matter if the information gets lost when you ftp the file or
copy the file using a non-multi-fork aware application. For example,
the icon of the file, so the display manager can more easily figure out
what icon to associate with the file --- and of course, some people
would argue with the notion that the icon isn't critical information,
and that it should be preserved, in which case putting it in a alternate
stream may not be such a hot idea.
However, for speed reasons, a graphical file manager might do better to
have a single file that has all of the icons cached in a few dot files
(for security reasons, you will need a different dot file for each user
who owns files in a directory). Said dot file would have information
associating the name of the file, the inode number and mod time with the
icon. If the icon cache is out of date, and an file appears in a
directory without also updating the icon cache, the graphical file
manager will have to find some way of determining the right icon to
associate with the file. (But, this is a problem the graphical file
manager would have to deal with anyway). The advantage of using a few
dot files in each directory is that it will result in a lot fewer system
calls and files needs that need read and touched than if the graphical
file manager has to open the icon resource fork in each file just to
determine which icon to display for that one file. So I don't even buy
the argument multifork files are required to make graphical file
managers faster; a few dot files in each directory would actually be
more efficient, and would work across non-multi-fork aware remote
filesystems like NFS. I don't think a graphical file manager that only
worked on specialized filesystems would be all that well received!
So before we design filesystems that support multi-forks, let's please
think about how they will be used, and how they will interact with
current systems that don't really support multiple forks, and in fact
are quite hostile to the whole concept. What's the point of being able
to treat a filesystem object as both directory and a file if none of the
system utilities, file formats (like tar) and internet protocols don't
really support it? Does it really buy us enough to be worth the effort?
And if we don't know exactly how it will be used, how will we know what
sort of performace/feature tradeoffs we need to make before it will be
useful?
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/