Suggestion for change in the vfs_ops structure?

[Andrew Bartlett]

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 at sys, ...) and substitute the
> > > defined AFS sysname for @sys, so that e.g. for a Windows 2000 client foo- at 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- at 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- 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.

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