On Windows, if "file link" is used to create a link
from a location outside vfs space to a location that is
real but referenced by a virtual filesystem, the glob
and file commands give inconsistent results as to
whether the relevant vfs handler code is accessed.
To reproduce:
create two real directories:
% file mkdir C:/temp/test
% file mkdir C:/temp/vfs
create a unique file in each directory:
% close [open C:/temp/test/test.txt w]
% close [open C:/temp/vfs/vfs.txt w]
create an OS-level link to the real directory "test":
% file link C:/temp/link C:/temp/test
verify that this link shows the contents of "test":
% glob -dir C:/temp/link *
C:/temp/link/test.txt
% file exists C:/temp/link/test.txt
1
The attached file contains a virtual file system that
simply mirrors one directory to another. In this case,
the mount point of the vfs will be the same as the real
directory C:/temp/test, making it a virtual location
that mirrors C:/temp/vfs.
% source templatevfs.tcl
% vfs::template::Mount C:/temp/vfs C:/temp/test
verify that C:/temp/test now mirrors C:/temp/vfs:
% glob -dir C:/temp/test *
C:/temp/test/vfs.txt
% file exists C:/temp/test/vfs.txt
1
but now notice the behavior of C:/temp/link has changed:
% glob -dir C:/temp/link *
C:/temp/link/test.txt
% file exists /temp/link/test.txt
0
% file exists /temp/link/vfs.txt
1
The glob command works as before, but other file
functions for some reason trigger Tclvfs and cause the
vfs handler to be called on the location to which
C:/temp/link is linked.
As far as I can see, there is no reason why Tclvfs
should involve itself in file commands accessing the
linked location. Linking is an OS-level activity, only
the operating system should know that C:/temp/link is
the same as C:/temp/test. The file commands should be
able to access the link cleanly without Tclvfs ever
becoming involved.
The fact that glob and file act differently leads me to
conclude that there's a bug here somewhere, no matter
how you slice it.
Template vfs code