Suggestion for change in the vfs_ops structure?

[Kris Van Hees]

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

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