Suggestion for change in the vfs_ops structure?

Kris Van Hees aedil at
Wed Nov 13 06:32:00 GMT 2002

On Wed, Nov 13, 2002 at 05:16:38PM +1100, Andrew Bartlett wrote:
> Well, I think making the MSDFS resolving code pluggable would be a good
> thing.


> > > MSDFS works by the server attempting saying 'not here' to a file open. 
> > > The client then asks there server for 'where is is then', and the server
> > > gives a new UNC path.
> > 
> > You are right that I may not understand how MSDFS works.  Would the redirect
> > request need to be replied to with a deeper path within the share that the
> > client was already accessing?  E.g. if the client tries to access the following
> > path:
> > 
> > 	\\afs-server\dist\OS\bin- at sys
> > 
> > would a valid redirect value be
> > 
> > 	\\afs-server\dist\OS\bin-i386_win2k
> > 
> > as far as MSDFS is concerned?  More explicitly, must the redirect reply point
> > to a share or can it be to a specific file or directory within a share (even
> > the same share as where the original request was sent for)?
> I really should check with the people who actually wrote this, but I
> think that is valid - as long as the @sys represents a folder.

That is a possible show-stopper since @sys can be used both in directory names
and in actual file names.

> > > It is not 'resolved' on each access, and as such subsequent accesses do
> > > not take any performance penalty.
> > 
> > The main question becomes in this case whether in MSDFS the Windows client is
> > going to cache the result from the redirection or not.  E.g. if I first try to
> > access \\afs-server\dist\OS\bin- at sys, and then a few minutes later I decide to
> > go back to that location, will MS Windows automatically contact the redirected
> > version or will it once again try to resolve it in the parent share, and have
> > the Samba server send a 'not here' response and then query for the actual
> > (redirected) location?
> My understanding is that such redirects are cached.

A possible show-stopper for using MSDFS directly, as I mention below...

> > Its semantics could be described as a dynamic symbolic link, yes.  Its target
> > is dependent on the client machine's architecture.  The reason why the Samba
> > server has to deal with this is that a Samba server running on an AFS client
> > machine would otherwise pass the pathname down to the underlying filesystem
> > (AFS) where the @sys token would be translated using the architecture sysname
> > for the Samba server machine, and not for the Windows client machine.
> As long as it is presented to Samba as a broken symbolic link, I think
> this would not be too hard to implement.

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.

> > The finer detail is that if at any point the sysname for the client architecture
> > would change (which is another thing I am working on since it is needed), the
> > target of any further pathnames that contain a @sys token must resolve using the
> > new sysname value.  That is why I ask about possible MSDFS redirection caching
> > above, since that could violate these real time sysname change semantics.
> I'm not quite sure what you mean here - the client's arch value isn't
> going to change for the life of an SMB session nor the life of the
> client installation for that matter :-)

Well, although specific sysname values are assigned for specific architectures
(CPU - OS specific), some AFS environments tend to assign arbitrary sysnames
to allow for a finer grained differentiation of systems.  E.g. using different
sysnames for NT 4 SP 2 and NT 4 SP 3.  It is not uncommon to initially use the
default sysname to get your system started using networked resources, and to
then set the actual sysname you want for overall operation of the client

It is a bit of a pain, and fortunately not often used, but the semantics in AFS
allow for it, so I have to support it :(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 290 bytes
Desc: not available
Url :

More information about the samba-technical mailing list