Apologies if this is an old idea, but:
Tridge's remarks in his recent interview make me think maybe Wine should be using the same NTVFS layer that Samba4 does. Who knows, maybe it'd be an easy fit... - Dan
http://software.newsforge.com/article.pl?sid=05/04/08/2132221&from=rss
NF: What are the biggest improvements that have come to fruition in Samba4 and what are the biggest ones that didn't make it or had to be significantly trimmed?
Tridge: From my point of view, the biggest improvement is in the code structure. Over half the code in Samba4 is now auto-generated using a new compiler we wrote for the task. That change alone would be worth the effort for me. The code that isn't auto-generated is structured in a modular and very efficient manner. That point of view isn't what users care about, of course, but it does lead to lots and lots of user-visible improvements due to the ease of programming with the new structure. We now commonly come across situations where we say, "OK, let's start on the following feature," and a couple of hours later it's finished, where we might have spent a week or more on the same feature in Samba3. The most user-visible changes in Samba4 will be those associated with the ADS support, and the additional file system features. The file system features are what started the whole Samba4 effort -- Samba4 was initially called the "Samba NTVFS" project, referring to the new virtual file system layer that allows for NT semantics on top of both POSIX and non-POSIX file systems.
One simple but important example of how the new NTVFS layer helps is the addition of support for "NT file streams." A file in a NT filesystem can have multiple "streams," where the primary stream (called ":$DATA") is the normal file data that people are used to thinking about, but there can be any number of other named streams containing other types of data, such as meta-data describing who wrote the file, or an audio stream, or even some data from an anti-virus scan of the file. Importantly, recent updates to WindowsXP use streams to store security information about where a file came from, which allows Windows to display a warning when you try to execute a file that comes from an untrusted "security zone." POSIX file systems have no concept of multiple streams, and as Samba was originally designed as a tool for representing a POSIX filesystem to Windows clients, there was no attempt to add stream support. The situation has now changed, with streams becoming a more essential feature for a file server for Windows clients, and at the same time user expectations for compatibility with WindowsNT have risen. This means we really need to support streams, but in order to do that properly, a lot of the internals of Samba needed to be updated. This is achieved in Samba4 using the new NTVFS layer, which allows streams to be represented either using an external database or using "file xattrs," which is an extension recently added to Linux, and which is also present in a number of other, Unix-like systems
