When using "file join" on a string that happens to include a virtual volume name as a substring, the string is improperly split at the substring boundary, and the command acts as though there were a space at the substring boundary.
For convenience I have attached a file (templatevfs.tcl) to make it easy to create a virtual volume by mounting a virtual filesystem, but the issue should not be construed as limited to this vfs.
Example:
% cd
% file mkdir testvfs
% source templatevfs.tcl
% vfs::template::mount -volume testvfs testvfs
testvfs
%file volumes ; # note testvfs is now a virtual volume
testvfs /
% file join testvfstest ; # expect response: testvfstest
testvfs/test
Note in the last statement "testvfstest" is an arbitrary string which just happens to start with "testvfs". The command "file join testvfstest" should simply echo the argument string. But the command acts as if there were a space between "testvfs" and "test".
Also note:
% file join foo testvfstest
testvfs/test
Discarding "foo" would be expected if there were a space between "testvfs" and "test", since the command discards arguments that come before a volume name. But the response should be "foo/testvfstest". This illustrates that "testvfs" is being treated as a volume name rather than as a substring.
Tested on Ubuntu Hardy.
template vfs code
At the point of failure, what does
[file pathtype testvfstest] return?
The values returned by [file system testvfstest]
and [file normalize testvfstest] might be useful
as well.
After executing the steps above:
% file join testvfstest
testvfs/test
% file pathtype testvfstest
absolute
% file system testvfstest
native
% file normalize testvfstest
<home>/testvfs/test
Thanks for the replies.
Since "testvfstest" is seen as
an absolute path, [file join] is behaving
properly as documented.
The bug, if there is one, is the combination
of results you just posted. Whether the
flaw is in Tcl, tclvfs, the vfs::template driver,
or your code, I cannot say without diving
deeper. Can you, or someone in any
of those projects say with more clarity,
which of the command outcomes you
posted are incorrect, and why?
Thanks.
It is incorrect for [file pathtype] to return a value of "absolute" in the given example. Since there is no path separator in the string "testvfstest", the only time [file pathtype testvfstest] should return "absolute" would be if there were a mounted volume named "testvfstest", but there isn't.
It is also incorrect for [file join testvfstest] to return "testvfs/test", even if it were correct that testvfstest was an absolute path. If [file join] is passed an absolute path as the sole argument, the argument should be returned unchanged. If [file join] is passed an arbitrary string that doesn't correspond to an existing file, the string should also be returned unchanged. Whichever is the case, [file join] should simply pass the argument back unchanged.
There is no file or volume named "testvfstest". The handler code written by me is not called when either the [file pathtype] command or the [file join] command is executed. Thus the problem is either with Tcl or the Tclvfs extension.
Reproduced on all the branches 8-4, 8-5, and HEAD,
as well as in the 8.4.0 release.
This looks like part operator error, and part a bug
in either tclvfs or the driver.
The mount command created a new
volume "testvfs" which means *every*
path that begins with that substring is
now an absolute pathname in the filesystem
controlling that volume. This is why
[file pathype testvfstest] is reporting "absolute".
If what you really wanted was to only have
pathnames beginning with "testvfs/" to be
in the volume, then I think the command
should have been:
vfs::template::mount -volume testvfs testvfs/
See if you are happier with the results of that
change. At a minimum that is a workaround.
A bug which seems to be contributing to
problems is that if all paths beginning with the
prefix substring "testvfs" are now to belong to
that volume, then they should be claimed by
the filesystem that has control over that volume,
which means
[file system testvfstest] => native
is an incorrect result. This seems likely
to me to be a failure of the filesystem driver
to claim a path that belongs to it. Precisely
where that bug is, I do not yet know.
If you have a different understanding about
how these things are supposed to properly
work, please point me to the docs that support
your view.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).