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-@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-@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-@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-@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 [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
signature.asc
Description: This is a digitally signed message part
