Menu

#4448 unexpected absolute path with vfs

obsolete: 8.5.5
closed
7
2009-11-18
2009-10-27
No

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.

Discussion

  • Stephen Huntley

    Stephen Huntley - 2009-10-27

    template vfs code

     
  • Don Porter

    Don Porter - 2009-10-27

    At the point of failure, what does
    [file pathtype testvfstest] return?

     
  • Don Porter

    Don Porter - 2009-10-27
    • assigned_to: vincentdarley --> dgp
    • priority: 5 --> 7
    • status: open --> pending
     
  • Don Porter

    Don Porter - 2009-10-27

    The values returned by [file system testvfstest]
    and [file normalize testvfstest] might be useful
    as well.

     
  • Stephen Huntley

    Stephen Huntley - 2009-10-28

    After executing the steps above:

    % file join testvfstest
    testvfs/test
    % file pathtype testvfstest
    absolute
    % file system testvfstest
    native
    % file normalize testvfstest
    <home>/testvfs/test

     
  • Stephen Huntley

    Stephen Huntley - 2009-10-28
    • status: pending --> open
     
  • Don Porter

    Don Porter - 2009-10-28

    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.

     
  • Don Porter

    Don Porter - 2009-10-28
    • status: open --> pending
     
  • Don Porter

    Don Porter - 2009-10-28
    • summary: "file join" improperly injects space --> unexpected absolute path with vfs
     
  • Stephen Huntley

    Stephen Huntley - 2009-10-31

    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.

     
  • Stephen Huntley

    Stephen Huntley - 2009-10-31
    • status: pending --> open
     
  • Don Porter

    Don Porter - 2009-11-03

    Reproduced on all the branches 8-4, 8-5, and HEAD,
    as well as in the 8.4.0 release.

     
  • Don Porter

    Don Porter - 2009-11-03

    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.

     
  • Don Porter

    Don Porter - 2009-11-03

    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.

     
  • Don Porter

    Don Porter - 2009-11-03
    • status: open --> pending
     
  • SourceForge Robot

    • status: pending --> closed
     
  • SourceForge Robot

    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).