I am seeing some odd behavior on a Solaris 8 system. If I try to
access a symlinked file, reduce_name is having a problem with the link
    
>From a level 10 log:
    
[2003/05/12 11:50:12, 3, pid=18558] lib/util.c:(387)
  unix_clean_name [/disk2/OC192/syee_test1.bat]
[2003/05/12 11:50:12, 3, pid=18558] smbd/vfs.c:(800)
  reduce_name [disk2/OC192/syee_test1.bat] [/vobstore]
[2003/05/12 11:50:12, 3, pid=18558] smbd/vfs.c:(574)
  vfs_ChDir to disk2/OC192
[2003/05/12 11:50:12, 3, pid=18558] smbd/vfs.c:(574)
  vfs_ChDir to /vobstore
[2003/05/12 11:50:12, 3, pid=18558] smbd/vfs.c:(744)
  reduce_name: file path name /vobstore/disk2/OC192/syee_test1.bat is a symlink
  Checking it's path
[2003/05/12 11:50:12, 3, pid=18558] lib/util.c:(387)
  unix_clean_name [/vobstore/../SYEE/syee_test1.bat]
    
The file
    
/vobstore/disk2/OC192/syee_test1.bat is a relative symlink to
/vobstore/disk2/SYEE/syee_test1.bat
    
That is, /vobstore/disk2/OC192 contains
syee_test1.bat -> ../SYEE/syee_test1.bat


[2003/05/12 11:50:12, 2, pid=18558] smbd/vfs.c:(755)
  Bad access attempt? s=/vobstore/disk2/OC192/syee_test1.bat dir=/vobstore
+newname=/SYEE/syee_test1.bat l=9

For some reason, it's parsing the symlink as
    
/vobstore/SYEE/syee_test1.bat, leaving out the disk2 component.
    

[2003/05/12 11:50:12, 3, pid=18558] smbd/vfs.c:(574)
  vfs_ChDir to /vobstore/disk2/OC192
[2003/05/12 11:50:12, 2, pid=18558] smbd/vfs.c:(864)
  Bad access attemt? disk2/OC192/syee_test1.bat is a symlink outside the share
+pathcall_trans2qfilepathinfo: check_name of disk2/OC192/syee_test1.bat failed
(Error 0)

The very odd part is that if the symlink is an absolute symlink, it
works fine.
  
Just to confuse things further, if I reproduce this structure on
another server, it never appears to call reduce_name -- it just goes
ahead and reads the file.
    
The pattern of access in the 2 level 10 logs is different. The 2 logs
files are about 600 lines each.

I hesitate to attach them here but can provide them if someone can
take a look.