Borrowing NTVFS layer from Samba4 for Wine?

[Andrew Bartlett]

On Thu, 2005-04-14 at 14:47 +0900, Mike McCormack wrote:
> Dan Kegel wrote:
> 
> >> I see it this way - wine will need a full NTFS redirector at some point,
> >> to correctly handle remote fileystems.  Why is the local disk any
> >> different from a remote redirected filesystem?  Samba could be hooked in
> >> at this point (and my even assist in providing access to those remote
> >> files).
> 
> The local disk is not different from a remote redirected filesystem - 
> they are both accessed through the kernel.  ie. there is no remote 
> filesystem support in Wine, only in the Linux Kernel.

Is that a long-term viable position however?  My view is that POSIX and
the Linux kernel will never be rich enough to provide full NTFS
semantics.  We will always have to add them on top, and why force Wine
(and the same applies to samba) though that restricted layer, when the
remote FS does not require it?

> > I suppose one could do it that way, but I was thinking
> > of turning Samba4's NTVFS layer into an ELF shared library
> > that could be used either by Samba or by Wine
> > (or both).  That way it'd be easier to simulate local
> > Windows disks accurately; doing it via Samba would make
> > them seem like network disks, which sometimes wouldn't be
> > good enough, I bet.
> > - Dan
> 
> Without having a process wide lock of some kind, the only way to use a 
> shared library for the VFS would be in the Wine server.  Implementing 
> reading and writing via wineserver has pretty bad performance penalties.

Yes, it introduces network-like latencies to the problem.  It also gives
us a chance to be 'truly correct'.

I wonder which of the points are actually performance hot-spots, and
whether these could be optimised once we know what they are?  (I don't
know the history, perhaps some of this has been tried before). 

> IMO, the best way is to add what we need to the Linux kernel.
> 
> If we were to extend smbfs or cifs to allow access to the NTFS data that 
> the unix VFS doesn't allow, that would provide us with fast and atomic 
> access to remove NTFS filesystems.

From rom the Samba perspective, I just don't see this as a viable way
forward.  Perhaps it's best to provide a bit of history here, as to why
Samba4 got started in the first place:

Samba4 was started, because tridge was working for IBM research on an
advanced network storage solution, which included it's own network file-
system, capable of providing full NTFS semantics.

While the file-system clearly worked with Samba being a POSIX app, and
the remote FS mounted in the kernel, providing proper NTFS semantics was
simply not possible: so much information was lost on the POSIX
transition.  Tridge then worked to construct a VFS layer for Samba that
allowed a pluggable object to provide the full NTFS semantics.  It is
this pluggable interface we are discussing here.  This interface has a
CIFS backend, as well as the 'posix' backend we use for storing real
files locally, and this does work.  

So, what I'm trying to say is this: why should wine loose all this
information as it tries to push things though to POSIX interface of the
kernel?  Even extended, I just don't see that interface providing
consistent support for a remote filesystem in the way windows works, and
for local filesystems, there is still the need for someone (Samba, wine,
the Linux kernel?) to provide all the other databases, like locking and
share modes. 

> Just got another mail from Dan while writing:
> 
> > On second thought, NTVFS ought to move into the Linux kernel.
> > Then both Samba and Wine would use native NTFS Win32 API calls
> > implemented by Linux directly.
> 
> Yeah, I think that is the best way forward.

We can't get case-insensitivity into the Linux kernel, do you really
think we will get full NTFS in there instead?  Even if it did, how long
would it take for the BSD nuts to scream when Wine requires Linux ;-)

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050414/97ba0c48/attachment.pgp