Suggestion for change in the vfs_ops structure?

[Kris Van Hees]

On Wed, Nov 13, 2002 at 06:09:05PM +1100, Andrew Bartlett wrote:
> On Wed, 2002-11-13 at 17:28, Kris Van Hees wrote:
> > Well, that is not the case, since for the underlying filesystem it is usually a
> > very valid name.  The fact is just that they would resolve to different targets.
> > The Samba server (let's assume it is a Solaris box) would natively resolve it
> > to something that includes its sysname (sun4x_58 for example) whereas for the
> > Windows client it would need to resolve to something like i386_win2k.  And in
> > most cases, both would exist as targets, so it would not appear as a broken
> > symbolic link.
> 
> Well, it really depends on what you are trying to do - provide AFS to
> clients over samba, or provide a service to clients over Samba.  If you
> really want full AFS semantics, why not use the native AFS client?

What I am doing (at this stage) is providing all or part of the AFS filespace
as a share to Windows clients by means of Samba, with support for the @sys
translation that AFS supports because otherwise the translation would be done
in the AFS client code itself, for the wrong architecture.

It is very similar to the existing NFS-to-AFS translator, which provides for
sharing the AFS filespace through NFS.  The difference there is that it could
be implemented as part of AFS itself.

> If you want to provide a service, with @sys as an extra feature, then I
> think that MSDFS provides a way to do this.
> 
> If you really want AFS semantics and are willing to put in the legwork,
> then I would suggest you write a VFS module that actually implements AFS
> directly, ie not via the kernel.

Given the complexity of the AFS client code, that would be an enormous task.
You'd end up with a VFS module that is likely to be larger than Samba itself.
Fortunately, no one really wants a full fledged implementation of the AFS
semantics in Samba (that I know of).

> AFS ACLs and the like are so different to Unix that bypassing that layer
> really does start to make sense, and you don't need nearly as many hacks
> to get the right individual semantics.
> 
> However, you can do your translation stuff with just a standard VFS
> module - the main challenge would be memory management.  In the way that
> the audit module just passes along parameters, your module could pass on
> modified (and separately allocated) parameters to the default functions.

It seems we went full circle on this, because that is what I originally talked
about...  I implemented this and it won't work because the VFS functions can't
modify the pathnames that are passed to them (due to the const qualifier on
them - and the calling code often if not always passes in a copied string by
means of the dos_to_unix_static() functions that is called on them).  It seems
that an additional function as I proposed before to handle translation of the
pathname (vfs_redirect() for lack of a better name) would be useful, because
it is both flexible, and it allows for calling code to also explicitly get a
translated pathname where needed.

Or the alternative...  changing the RESOLVE_DFSPATH() macro (and related macros)
to also check whether there is a vfs_redirect() function defined for the
current connection and if so, calling it, might do the trick.

I like the first alternative better though, because it seems more generic and
it makes it possible to internally resolve the pathnames that contain @sys to
their true values, while still allowing the client to keep thinking that the
unmodified one is the true one (in case the Windows client actually cares if
what it gets back might be a different pathname than it requested).  That also
covers the fact that e.g. on Unix in AFS if you cd @sys, pwd will show the @sys
component rather than the translated name.

> Or take a different approach:  Tell the kernel what your arch is.  Why
> can't the kernel do the correct translation for you?

Because if you have multiple clients connecting to your Samba server, they may
all have different architectures, thereby all needing their own sysname value
to be substituted for @sys.

> Well, I think you will have trouble getting that information to Samba -
> that's my point.  Samba can only really tell the difference between
> major client versions.  You could use the name in the session setup, but
> I'm not sure that changes between service packs.

Initially I am using the Samba-based detection of the remote architecture (for
which I added a check to detect WinXP as distinct from Win2K), but we are going
to use a metafile operation initiated by the client (e.g. writing to a symbolic
(virtual) filename) to set the sysname value to an arbitrary value, as override
for the default one that is based on the Samba detection code.  That allows for
the flexibility that is needed for this.

	Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 290 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20021113/b2566178/attachment.bin