On Wed, 2002-11-13 at 16:08, Kris Van Hees wrote: > On Wed, Nov 13, 2002 at 03:43:08PM +1100, Andrew Bartlett wrote: > > On Wed, 2002-11-13 at 15:24, Kris Van Hees wrote: > > > On Wed, Nov 13, 2002 at 03:08:26PM +1100, Andrew Bartlett wrote: > > > > Well, I think that doing so would be *very* dangerous. For one, what > > > > are you doing to do with those strings? Only change them in-place, but > > > > never extend them? You can realloc() those strings, as the pointer > > > > might change, or they might be stack strings, but of what size? > > > > > > Very good point. > > > > > > > And I'm glad it generates compiler warnings, because it should make you > > > > stop and think 'is this actually a good idea'. > > > > > > > > What exactly were you wanting to do anyway? > > > > > > Well, for AFS support I need to be able to allow people to use filenames that > > > end in @sys (such as @sys, /foo/@sys, /foo/bar@sys, ...) and substitute the > > > defined AFS sysname for @sys, so that e.g. for a Windows 2000 client foo-@sys > > > becomes foo-i386_win2k. All the code to do that in VFS operations is already > > > written, but there is still the issue that after e.g. a vfs_stat() is done on > > > such a filename, call_trans2findfirst() will call get_lanman2_dir_entry() to > > > check the passed in filename (foo-@sys) against the directory entries. It will > > > not find a match because that routine uses the actual contents of the current > > > directory, and matches it against the non-translated filename. > > > > > > Since it is likely that there are other cases where this happens, I would rather > > > not send in a patch that litters the Samba code with #ifdef's for AFS since that > > > is beyond ugly. A more generic interface that could potentially be used by > > > fugure other implementations would be much cleaner and easier to handle. > > > > > > What the best solution would be is not really clear though. I believe that a > > > VFS function that returns a possibly altered filename for a given filename would > > > be useful in this sense, but whether that would be an acceptable way to do it > > > might be debateable on your end given that it would impose a tiny overhead on > > > cases where the default VFS is not overloaded, because you'd still need to have > > > a dummy function that returns the passed in argument unaltered. > > > > Why can't you solve this with MSDFS? It is relatively easy to add > > support either as per-the current implementation (and people have asked > > for % expansion in that) or by adding magic overrides over the entire > > namespace. That way, every file access (and stat() is something we call > > a *lot*) won't have to do this legwork. > > 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. 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. It is not 'resolved' on each access, and as such subsequent accesses do not take any performance penalty. > > 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. > > Also, keep the list CC'ed, because I certainly won't be applying any VFS > > patches. > > Hereby done. Thanks, I didn't notice that my reply to you was a plain reply > rather than a group reply. My bad. > > Kris -- 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
