Re: Suggestion for change in the vfs_ops structure?
On Thu, 2002-11-14 at 03:18, Kris Van Hees wrote: > On Wed, Nov 13, 2002 at 06:09:05PM +1100, Andrew Bartlett wrote: > > On Wed, 2002-11-13 at 17:28, Kris Van Hees wrote: > > > Well, that is not the case, since for the underlying filesystem it is usually a > > > very valid name. The fact is just that they would resolve to different targets. > > > The Samba server (let's assume it is a Solaris box) would natively resolve it > > > to something that includes its sysname (sun4x_58 for example) whereas for the > > > Windows client it would need to resolve to something like i386_win2k. And in > > > most cases, both would exist as targets, so it would not appear as a broken > > > symbolic link. > > > > Well, it really depends on what you are trying to do - provide AFS to > > clients over samba, or provide a service to clients over Samba. If you > > really want full AFS semantics, why not use the native AFS client? > > What I am doing (at this stage) is providing all or part of the AFS filespace > as a share to Windows clients by means of Samba, with support for the @sys > translation that AFS supports because otherwise the translation would be done > in the AFS client code itself, for the wrong architecture. > > It is very similar to the existing NFS-to-AFS translator, which provides for > sharing the AFS filespace through NFS. The difference there is that it could > be implemented as part of AFS itself. > > > If you want to provide a service, with @sys as an extra feature, then I > > think that MSDFS provides a way to do this. > > > > If you really want AFS semantics and are willing to put in the legwork, > > then I would suggest you write a VFS module that actually implements AFS > > directly, ie not via the kernel. > > Given the complexity of the AFS client code, that would be an enormous task. > You'd end up with a VFS module that is likely to be larger than Samba itself. > Fortunately, no one really wants a full fledged implementation of the AFS > semantics in Samba (that I know of). Well, you already have the cross-platform AFS client - the difference would be that this time it isn't a kernel module. Just a different front-end, I would have thought. > > AFS ACLs and the like are so different to Unix that bypassing that layer > > really does start to make sense, and you don't need nearly as many hacks > > to get the right individual semantics. > > > > However, you can do your translation stuff with just a standard VFS > > module - the main challenge would be memory management. In the way that > > the audit module just passes along parameters, your module could pass on > > modified (and separately allocated) parameters to the default functions. > > It seems we went full circle on this, because that is what I originally talked > about... I implemented this and it won't work because the VFS functions can't > modify the pathnames that are passed to them (due to the const qualifier on > them - and the calling code often if not always passes in a copied string by > means of the dos_to_unix_static() functions that is called on them). It seems > that an additional function as I proposed before to handle translation of the > pathname (vfs_redirect() for lack of a better name) would be useful, because > it is both flexible, and it allows for calling code to also explicitly get a > translated pathname where needed. No need. You just grab the string on the way into the module, strdup() it, modify it and pass it on it's way. No need for more magic inside smbd. > Or the alternative... changing the RESOLVE_DFSPATH() macro (and related macros) > to also check whether there is a vfs_redirect() function defined for the > current connection and if so, calling it, might do the trick. > > I like the first alternative better though, because it seems more generic and > it makes it possible to internally resolve the pathnames that contain @sys to > their true values, while still allowing the client to keep thinking that the > unmodified one is the true one (in case the Windows client actually cares if > what it gets back might be a different pathname than it requested). That also > covers the fact that e.g. on Unix in AFS if you cd @sys, pwd will show the @sys > component rather than the translated name. > > > Or take a different approach: Tell the kernel what your arch is. Why > > can't the kernel do the correct translation for you? > > Because if you have multiple clients connecting to your Samba server, they may > all have different architectures, thereby all needing their own sysname value > to be substituted for @sys. I've seen per-process namespace stuff on Linux that allowed smbd to tell XFS that filenames are case insensitive. You could use a similar hook for Samba to tell the kernel the remote arch. > > Well, I think you will have trouble getting that information to Samba - > > that's my point. Samba can only really tell the difference between > > major client versions. You could use the n
Re: Suggestion for change in the vfs_ops structure?
On Wed, Nov 13, 2002 at 06:09:05PM +1100, Andrew Bartlett wrote: > On Wed, 2002-11-13 at 17:28, Kris Van Hees wrote: > > Well, that is not the case, since for the underlying filesystem it is usually a > > very valid name. The fact is just that they would resolve to different targets. > > The Samba server (let's assume it is a Solaris box) would natively resolve it > > to something that includes its sysname (sun4x_58 for example) whereas for the > > Windows client it would need to resolve to something like i386_win2k. And in > > most cases, both would exist as targets, so it would not appear as a broken > > symbolic link. > > Well, it really depends on what you are trying to do - provide AFS to > clients over samba, or provide a service to clients over Samba. If you > really want full AFS semantics, why not use the native AFS client? What I am doing (at this stage) is providing all or part of the AFS filespace as a share to Windows clients by means of Samba, with support for the @sys translation that AFS supports because otherwise the translation would be done in the AFS client code itself, for the wrong architecture. It is very similar to the existing NFS-to-AFS translator, which provides for sharing the AFS filespace through NFS. The difference there is that it could be implemented as part of AFS itself. > If you want to provide a service, with @sys as an extra feature, then I > think that MSDFS provides a way to do this. > > If you really want AFS semantics and are willing to put in the legwork, > then I would suggest you write a VFS module that actually implements AFS > directly, ie not via the kernel. Given the complexity of the AFS client code, that would be an enormous task. You'd end up with a VFS module that is likely to be larger than Samba itself. Fortunately, no one really wants a full fledged implementation of the AFS semantics in Samba (that I know of). > AFS ACLs and the like are so different to Unix that bypassing that layer > really does start to make sense, and you don't need nearly as many hacks > to get the right individual semantics. > > However, you can do your translation stuff with just a standard VFS > module - the main challenge would be memory management. In the way that > the audit module just passes along parameters, your module could pass on > modified (and separately allocated) parameters to the default functions. It seems we went full circle on this, because that is what I originally talked about... I implemented this and it won't work because the VFS functions can't modify the pathnames that are passed to them (due to the const qualifier on them - and the calling code often if not always passes in a copied string by means of the dos_to_unix_static() functions that is called on them). It seems that an additional function as I proposed before to handle translation of the pathname (vfs_redirect() for lack of a better name) would be useful, because it is both flexible, and it allows for calling code to also explicitly get a translated pathname where needed. Or the alternative... changing the RESOLVE_DFSPATH() macro (and related macros) to also check whether there is a vfs_redirect() function defined for the current connection and if so, calling it, might do the trick. I like the first alternative better though, because it seems more generic and it makes it possible to internally resolve the pathnames that contain @sys to their true values, while still allowing the client to keep thinking that the unmodified one is the true one (in case the Windows client actually cares if what it gets back might be a different pathname than it requested). That also covers the fact that e.g. on Unix in AFS if you cd @sys, pwd will show the @sys component rather than the translated name. > Or take a different approach: Tell the kernel what your arch is. Why > can't the kernel do the correct translation for you? Because if you have multiple clients connecting to your Samba server, they may all have different architectures, thereby all needing their own sysname value to be substituted for @sys. > Well, I think you will have trouble getting that information to Samba - > that's my point. Samba can only really tell the difference between > major client versions. You could use the name in the session setup, but > I'm not sure that changes between service packs. Initially I am using the Samba-based detection of the remote architecture (for which I added a check to detect WinXP as distinct from Win2K), but we are going to use a metafile operation initiated by the client (e.g. writing to a symbolic (virtual) filename) to set the sysname value to an arbitrary value, as override for the default one that is based on the Samba detection code. That allows for the flexibility that is needed for this. Kris msg04436/pgp0.pgp Description: PGP signature
Re: Suggestion for change in the vfs_ops structure?
On Wed, 2002-11-13 at 17:28, Kris Van Hees wrote: > On Wed, Nov 13, 2002 at 05:16:38PM +1100, Andrew Bartlett wrote: > > Well, I think making the MSDFS resolving code pluggable would be a good > > thing. > > Agreed. > > > > > 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. > > That is a possible show-stopper since @sys can be used both in directory names > and in actual file names. > > > > > 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. > > A possible show-stopper for using MSDFS directly, as I mention below... > > > > 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. > > Well, that is not the case, since for the underlying filesystem it is usually a > very valid name. The fact is just that they would resolve to different targets. > The Samba server (let's assume it is a Solaris box) would natively resolve it > to something that includes its sysname (sun4x_58 for example) whereas for the > Windows client it would need to resolve to something like i386_win2k. And in > most cases, both would exist as targets, so it would not appear as a broken > symbolic link. Well, it really depends on what you are trying to do - provide AFS to clients over samba, or provide a service to clients over Samba. If you really want full AFS semantics, why not use the native AFS client? If you want to provide a service, with @sys as an extra feature, then I think that MSDFS provides a way to do this. If you really want AFS semantics and are willing to put in the legwork, then I would suggest you write a VFS module that actually implements AFS directly, ie not via the kernel. AFS ACLs and the like are so different to Unix that bypassing that layer really does start to make sense, and you don't need nearly as many hacks to get the right individual semantics. However, you can do your translation stuff with just a standard VFS module - the main challenge would be memory management. In the way that the audit module just passes along parameters, your module could pass on modified (and separately allocated) parameters to the default functions. Or take a different approach: Tell the kernel what your arch is. Why can't the kernel do the correct translation for you? > > > 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 :-) > > Well, although specific sysn
Re: Suggestion for change in the vfs_ops structure?
On Wed, Nov 13, 2002 at 05:16:38PM +1100, Andrew Bartlett wrote: > Well, I think making the MSDFS resolving code pluggable would be a good > thing. Agreed. > > > 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. That is a possible show-stopper since @sys can be used both in directory names and in actual file names. > > > 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. A possible show-stopper for using MSDFS directly, as I mention below... > > 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. Well, that is not the case, since for the underlying filesystem it is usually a very valid name. The fact is just that they would resolve to different targets. The Samba server (let's assume it is a Solaris box) would natively resolve it to something that includes its sysname (sun4x_58 for example) whereas for the Windows client it would need to resolve to something like i386_win2k. And in most cases, both would exist as targets, so it would not appear as a broken symbolic link. > > 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 :-) Well, although specific sysname values are assigned for specific architectures (CPU - OS specific), some AFS environments tend to assign arbitrary sysnames to allow for a finer grained differentiation of systems. E.g. using different sysnames for NT 4 SP 2 and NT 4 SP 3. It is not uncommon to initially use the default sysname to get your system started using networked resources, and to then set the actual sysname you want for overall operation of the client system. It is a bit of a pain, and fortunately not often used, but the semantics in AFS allow for it, so I have to support it :( Kris msg04426/pgp0.pgp Description: PGP signature
Re: Suggestion for change in the vfs_ops structure?
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 ch
Re: Suggestion for change in the vfs_ops structure?
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). > 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)? > 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? > > > 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. 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. Kris msg04424/pgp0.pgp Description: PGP signature
Re: Suggestion for change in the vfs_ops structure?
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
Re: Suggestion for change in the vfs_ops structure?
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 @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). > 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 msg04419/pgp0.pgp Description: PGP signature
Re: Suggestion for change in the vfs_ops structure?
On Tue, Nov 12, 2002 at 09:20:59PM -0500, Kris Van Hees wrote: > Could the passed filenames and pathnames in the functions in vfs_ops be made > non-const? The use of a VFS module as transparent layer includes the ability > to change the passed data (as suggested from the comments in vfs.h), but with > the const qualifiers there, you cannot legally change the passed names without > generating compiler warnings. Actually, looking into this further, perhaps we'd be better served with adding a new function to the VFS api, char *vfs_translate(const char *) which takes a pathname and returns a possibly rewritten version of it. The default would be simply returning the pathname itself. This can be used in operations such as when calling get_lanman2_dir_entry() from call_trans2findfirst() to ensure that cached directory information can be matched. The main purpose (right now) is to support @sys resolving for AFS, so that e.g. d-@sys gets translated to d-i386_win2k and as such can be found to match a directory entry by that name. Kris PS: As Andrew responded before I finished this update, allowing the various VFS functions to change the passed in filename would be very dangerous.
Re: Suggestion for change in the vfs_ops structure?
On Wed, 2002-11-13 at 13:20, Kris Van Hees wrote: > Could the passed filenames and pathnames in the functions in vfs_ops be made > non-const? The use of a VFS module as transparent layer includes the ability > to change the passed data (as suggested from the comments in vfs.h), but with > the const qualifiers there, you cannot legally change the passed names without > generating compiler warnings. 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? 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? 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
