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
signature.asc
Description: This is a digitally signed message part
