Borrowing NTVFS layer from Samba4 for Wine?
dank at kegel.com
Wed Apr 13 14:48:47 CDT 2005
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...
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
More information about the wine-devel