On Thu, 2002-11-14 at 03:18, Kris Van Hees wrote:
> 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).
Well, you already have the cross-platform AFS client - the difference
would be that this time it isn't a kernel module. Just a different
front-end, I would have thought.
> > 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.
No need. You just grab the string on the way into the module, strdup()
it, modify it and pass it on it's way. No need for more magic inside
smbd.
> 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.
I've seen per-process namespace stuff on Linux that allowed smbd to tell
XFS that filenames are case insensitive. You could use a similar hook
for Samba to tell the kernel the remote arch.
> > 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 n
