Re: (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and

Albert D. Cahalan (acahalan@cs.uml.edu)
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/