>>> On 2/10/2006 at 1:47:40 pm, in message <[EMAIL PROTECTED]>, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: >> Bottom line is that neither of the results in the test seem valid on >> NetWare. Returning APR_SUCCESS with a path of "/" seems wrong because >> an assumption is being made about what "/" means. And returning >> APR_EINCOMPLETE with a path of "//" seems wrong because the path isn't >> incomplete, it is invalid. > > Successive slashes are legal (and should be compressed).
Right, and they are being compressed inside of apr_filepath_root(). That's why the NetWare result is a single '/' rather than a double. This is exactly what the Unix implementation is doing. > > But I can see where you are right, if the Netware port doesn't accept the > '/foo' path, then it's wrong (but I thought '/foo' implies local:sys/foo). > So we should special-case this result on Netware. > > I'm almost of a mind that since 'machine:vol\path' is the normal syntax, and > we have several platforms which support similar, that we might want to > permit > '//machine/vol/path' on Netware as a portable syntax, accepting either > <shrug>. > > Bill The problem is that //machine/vol/path on NetWare can't be done without really hacking up the code throughout. So to avoid that, several years ago I created a module called mod_edir. One of its functions is supporting remote file system access. But it only understands the syntax 'machine\vol:\path' which is the common way of expressing a remote file system path on NetWare. Bascially what mod_edir does is switch the file IO connection under the covers so that when the path 'vol:\path' is handed to the libc file IO routines, the file path is assumed to be on a remote file system rather than local. Bottom line is that NetWare server to server file access is no where near seamless due to all of the security policies enforced by the OS. Which is the reason for the existence of mod_edir. Brad
