Suggestion for change in the vfs_ops structure?

[Andrew Bartlett]

On Wed, 2002-11-13 at 16:58, Kris Van Hees wrote:
> 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).

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.

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

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

As long as it is presented to Samba as a broken symbolic link, I think
this would not be too hard to implement.

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

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20021113/11be2ef9/attachment.bin