Messages in this thread | | | Date | Tue, 22 Jun 1999 12:36:58 -0400 | Subject | Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and loic | From | tytso@mit ... |
| |
Before we go running into a deep technical discussion about how to design different streams inside a file, we should first stop ask ourselves how they will be *used*.
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/
| |