#4295 file normalize breaks file pathtype

obsolete: 8.5.6
closed-fixed
9
2009-02-20
2009-02-06
No

On 8.6b1 using file pathtype after calling file normalize for the same argument is broken. See below :
(woof) 1 % file pathtype /a
volumerelative
(woof) 2 % file normalize /a
C:/a
(woof) 3 % file pathtype /a
relative

/Ashok

Discussion

  • Don Porter

    Don Porter - 2009-02-06
    • priority: 5 --> 8
    • assigned_to: vincentdarley --> dgp
     
  • Don Porter

    Don Porter - 2009-02-06

    The problems is reported for release 8.6b1.

    Can someone check and report whether the
    same issue is present in release 8.5.6 ?

     
  • Andreas Kupries

    Andreas Kupries - 2009-02-06

    A moment ...

    Found that I had a win32 8.5.6 still around, no need to build one for this ...

    andreask@ACTIVETCL-BU:~/dbn/lba/night-856/builds/win32-ix86/tcl/win/win32-ix86> ./tclsh85.exe
    puts [info patchlevel]
    8.5.6
    puts [file pathtype /a]
    volumerelative
    puts [file normalize /a]
    C:/a
    puts [file pathtype /a]
    relative
    exit

    Indeed 8.5.6 already has the problem.

     
  • Don Porter

    Don Porter - 2009-02-06

    Thanks for testing that.

    Is it easy to check whether the same
    issue was present in release 8.5.0 and
    whether it is present in 8.4.19 ?

     
  • Andreas Kupries

    Andreas Kupries - 2009-02-06

    In the original bug report (see my reference) the problem was not present in 8.5.3.
    Regarding 8.4.19 I will have to build something first (I did, for linux, which did not show the trouble, I am guessing because normalize had nothing to do).

     
  • Don Porter

    Don Porter - 2009-02-06

    based only on the timing then, I suspect
    the fault lies in this commit:

    2008-12-04 Don Porter <dgp@users.sourceforge.net>

    * generic/tclPathObj.c (Tcl_FSGetNormalizedPath): Added another
    flag value TCLPATH_NEEDNORM to mark those intreps which need more
    complete normalization attention for correct results. [Bug 2385549]

    A test that the problem is not present in
    release 8.5.5 would produce more evidence of that.

     
  • Don Porter

    Don Porter - 2009-02-06

    If that supposition is correct, the
    problem is likely also present on
    the tip of core-8-4-branch, and will
    introduce the bug into 8.4.20 if not
    fixed first.

     
  • Don Porter

    Don Porter - 2009-02-06
    • milestone: 897103 --> obsolete: 8.5.6
    • priority: 8 --> 9
     
  • Andreas Kupries

    Andreas Kupries - 2009-02-06

    Instead of having something built I am now using the ActiveTcl win32 releases on a virtual win32 test box ...

    % source k:/trans/x/pt.tcl
    patchlevel=8.6b1.1
    release...=8.6.0.0.289036/(Wed Jan 28 14:41:35 PST 2009)
    pathtype..=volumerelative
    normalized=C:/a
    pathtype..=relative
    %

    % source k:/trans/x/pt.tcl
    patchlevel=8.5.6
    release...=8.5.6.0.289017/(Tue Jan 27 14:06:08 PST 2009)
    pathtype..=volumerelative
    normalized=C:/a
    pathtype..=volumerelative
    %

    % source k:/trans/x/pt.tcl
    patchlevel=8.5.5
    release...=8.5.5.0.287690/(Wed Oct 15 20:38:44 PDT 2008)
    pathtype..=volumerelative
    normalized=C:/a
    pathtype..=volumerelative
    %

    Contents of pt.tcl

    puts patchlevel=[info patchlevel]
    puts release...=[package provide ActiveTcl]/($activestate::ActiveTcl(buildtime,fmt))
    puts pathtype..=[file pathtype /a]
    puts normalized=[file normalize /a]
    puts pathtype..=[file pathtype /a]

    The interesting thing here is that the 8.5.6 here is ok, contradicting the other 8.5.6 I mentioned in a previous comment. ... Redoing the experiment with that tclsh it is now ok too. ... Differences: I called this one in a dos box, the previous experiment used msys bash. This experiment used a script file (pt.tcl), the previous was interactive ...

    C:\night-856\builds\win32-ix86\tcl\win\win32-ix86>tclsh85.exe
    % info patchlevel
    8.5.6
    % parray activestate::ActiveTcl
    can't access "activestate::ActiveTcl": parent namespace doesn't exist
    % source k:/trans/x/pt.tcl
    patchlevel=8.5.6
    can't read "activestate::ActiveTcl(buildtime,fmt)": no such variable
    % source k:/trans/x/pt.tcl
    patchlevel=8.5.6
    release...=
    pathtype..=volumerelative
    normalized=C:/a
    pathtype..=volumerelative
    % clock format [file mtime [info nameofex]]
    Tue Jan 27 20:03:43 -0800 2009
    %

     
  • Don Porter

    Don Porter - 2009-02-20

    To better analyze this, separate
    the literal sharing issue from the
    proper functioning of [file pathtype]
    issue. Test the following script for
    proper functioning:

    set p /a
    file pathtype $p
    file normalize $p
    file pathtype $p

    Are there any Tcl releases where
    that produces the correct answers? :)

     
  • Nobody/Anonymous

    I tried 8.4.19, 8.5.2 and 8.6b1.

    (woof) 49 % set p /a
    /a
    (woof) 50 % file pathtype $p
    volumerelative
    (woof) 51 % file normalize $p
    C:/a
    (woof) 52 % file pathtype $p
    relative
    (woof) 53 % set tcl_version
    8.4

    The code breaks on all of them so it does look like it's been a bug that's been there for a while and now is more obviously exposed because of more aggressive sharing/caching of literals in 8.6b1

    /Ashok

     
  • Don Porter

    Don Porter - 2009-02-20

    The fix for Bug 767834 introduced
    this problem.

    Apparently the combination of the
    rare use of volumerelative paths
    and the rarity of actual re-use of
    cached intreps of "path" values (!)
    has allowed it to be undiscovered
    all that time.

    Bug introduced in releases 8.4.5 and
    8.5a1, or more precisely in Revisions
    1.77.2.9 of tclIOUtil.c and 1.7 of tclPathObj.c

     
  • Don Porter

    Don Porter - 2009-02-20

    fix committed to all branches.

     
  • Don Porter

    Don Porter - 2009-02-20
    • status: open --> closed-fixed