Suggestion for change in the vfs_ops structure?

[Kris Van Hees]

On Wed, Nov 13, 2002 at 04:24:22PM +1100, Andrew Bartlett wrote:
> On Wed, 2002-11-13 at 16:08, Kris Van Hees wrote:
> > I do not think that I should solve it with MSDFS itself, since that is a very
> > specific Microsoft thing.  Adding @sys resolution into that code would be a bit
> > messy, and confusing.  On the other hand, it might be worth abstracting the
> > RESOLVE_DFSPATH() macro to actually handle more than just MSDFS.  That way,
> > future enhancements could use the same mechanism.  I'd propose something that
> > (initially) does the current check for DFS, and then goes on to check whether
> > a VFS object has been installed.  If so, and if a specific function has been
> > implemented in the object (e.g. vfs_resolve()) it should be called and it can
> > change the filename pstring it is given (in the same way the dfs_resolve() may
> > do so).
> 
> I don't think you understand how MSDFS works, and I actually think it
> would solve this problem rather well actually.  And SMB is very
> MS-specific too, so I don't think that argument applies.  

What I meant is that MSDFS seems to be a specific function that in itself does
not know anything about the AFS @sys resolving.  Nothing in SMB does, but to
change the mechanics of MSDFS to add this @sys support seems to be more invasive
than to provide it as function of the standard lower level filesystem
implementation (since it *is* a function of the underlying filesystem anyway).

> 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)?

> 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?

> > > I @sys a magic AFS notion, or where does it come from?
> > 
> > The @sys token is a specific AFS defined token.  I do believe that similar
> > tokens (might even have been the same token) were used in earlier versions of
> > AIX to be able to have architecture-dependent pathnames resolve 'magically'
> > on the appropriate platforms (e.g. linking /bin- at sys to /bin so that any access
> > on /bin goes to /bin-i386_linux24 on a Linux 2.4.x based system, while it would
> > go to /bin-sun4x_58 on a Solaris 5.8 system).
> 
> So /bin- at sys would appear as a symbolic link, with the client to resolve
> it to something meaningful?  Sounds exactly like how MSDFS has been done
> in Samba.

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.

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.

	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/6a482954/attachment.bin