Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and | Date | Tue, 22 Jun 1999 19:49:01 -0400 (EDT) |
| |
tytso@mit.edu writes:
> 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*.
Yes, good question. I have answers. :-)
> 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
If the feature was only for Apple, I'd expect either a simple 2-fork system (likely merged with the OS/2 attribute support) or a 2-file solution like most Appleshare servers for UNIX.
> 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?
The answer involves something a bit like Hurd translators. Microsoft calls them "reparse points". It also involves a shared library, called a DLL in the Windows environment.
Microsoft has an API for handling *.doc files. This is implemented as a DLL that can make use of multi-forked files on NTFS and SMB filesystems. When using FAT and old SMB servers, the DLL reverts to older and slower ways of handling the data.
(the old methods suffer from garbage collection, holes filled with deleted data, object expansion and reallocation problems...)
You might wonder what older software will do when it encounters such a file. Anything using the proper API is handled by the DLL, but that leaves general tools like GNU tar. The NT kernel takes care of the remaining problems, using reparse point drivers to create an old-format file as needed.
No joke. We'd do this with loadable modules, much like masquerading has drivers for all the odd network protocols.
On an NTFS 5.0 filesystem, a multi-forked document file inode contains a reparse point driver ID number. These are globally assigned by Microsoft. For example, Office 2000 documents might be 0x12345678.
When GNU tar opens a multi-forked document file, the NT kernel sees that there is a reparse point ID code. This is used to look up a driver, most likely via the registry. We'd use kmod for it.
Reparse point drivers can do just about anything. They can be used to implement symlinks, persistent mount points, and any other odd feature that Microsoft desires. I suppose you could say that they change the file operations for the inode. Reparse points can have up to 16 kB of extra data in the inode (for parameters?).
In the GNU tar case above, the reparse point driver has a few options. The driver must create an old-style document file. This file could be thrown away, kept as a cache, or used to replace the multi-forked file. Similar options are available for tar extraction, and I'd guess that conversion to multi-forked format is deferred until an app asks for the data in multi-fork format.
> 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.
I hope you now understand how Microsoft solved this problem. The NTFS development mailing list is a good place to find out anything else you may wish to know.
- 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/
| |