file normalize breaks file pathtype

As a note. This was exposed by Tcllib's fileutil::jail command, see the Tcllib bug
https://sourceforge.net/tracker/?func=detail&atid=112883&aid=2499603&group_id=12883

The problems is reported for release 8.6b1.

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

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.

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 ?

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

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.

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.

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
%

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? :)

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

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

fix committed to all branches.