#3127 calling pwd after cd'ing to /c: crashes in Windows

I installed ActiveTcl 8.4.9.1 in directory c:/Program
files/Tcl . When I start tclsh from the start menu,
then type "cd /c:" (or any other drive letter) then
"pwd" it crashes with what looks like a segmentation
fault. If using the wish shell it crashes as soon as I
type "cd /c:" presumably because the prompt displays
the working directory. I have got the same result on a
Windows XP Home, a Windows 2000 Professional and a
Windows 98 machine.

This is bounced to you from ActiveState's own list as
it is a problem with core Tcl.

[Andreas Kupries]

Logged In: YES
user_id=75003

Corrected Category and responsible maintainer.

[Nobody/Anonymous]

Logged In: NO

This is indeed a bug (the crash), but I have to say that
"/c:" is not really a valid path at all on Windows. Perhaps
you mean "c/" or "c:" or "c:/" ?

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

This is caused by endless recursion where
TclFSEnsureEpochOk calls Tcl_FSGetNormalizedPath calls
Tcl_FSGetCwd calls Tcl_FSGetFileSystemForPath calls
TclFSEnsureEpochOk ... this case needs to be handled correctly.

Tcl_DStringAppend(Tcl_DString * 0x00033054, const char *
0x00887e28, int 2) line 1494 + 9 bytes
ExtractWinRoot(const char * 0x00887e28, Tcl_DString *
0x00033054, int 0, int * 0x00033148) line 231 + 15 bytes
TclpGetNativePathType(Tcl_Obj * 0x00898508, int *
0x00000000, Tcl_Obj * * 0x00000000) line 502 + 22 bytes
GetPathType(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x00000000, int * 0x00000000, Tcl_Obj * * 0x00000000) line
3519 + 17 bytes
FSGetPathType(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x00000000, int * 0x00000000) line 4723 + 19 bytes
Tcl_FSGetPathType(Tcl_Obj * 0x00898508) line 4677 + 13 bytes
Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, Tcl_Obj *
0x00898508) line 5665 + 9 bytes
TclFSEnsureEpochOk(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x00033260) line 5897 + 11 bytes
Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00898508) line 3901 +
13 bytes
Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2525 + 12 bytes
Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, Tcl_Obj *
0x00898508) line 5690 + 9 bytes
TclFSEnsureEpochOk(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x00033334) line 5897 + 11 bytes
Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00898508) line 3901 +
13 bytes
Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2525 + 12 bytes
Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, Tcl_Obj *
0x00898508) line 5690 + 9 bytes
TclFSEnsureEpochOk(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x00033408) line 5897 + 11 bytes
Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00898508) line 3901 +
13 bytes
Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2525 + 12 bytes
Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, Tcl_Obj *
0x00898508) line 5690 + 9 bytes
TclFSEnsureEpochOk(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x000334dc) line 5897 + 11 bytes
Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00898508) line 3901 +
13 bytes
Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2525 + 12 bytes
Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, Tcl_Obj *
0x00898508) line 5690 + 9 bytes
TclFSEnsureEpochOk(Tcl_Obj * 0x00898508, Tcl_Filesystem * *
0x000335b0) line 5897 + 11 bytes
Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00898508) line 3901 +
13 bytes
Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2525 + 12 bytes
Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, Tcl_Obj *
0x00898508) line 5690 + 9 bytes

[Kevin B KENNY]

Logged In: YES
user_id=99768

The problem is upstream from the endless recursion. By
the time the normalized path name is constructed, it's already
incorrect:

8.5 (correct):
% file normalize c:/
C:/c:

8.4 (wrong):
% file normalize c:/
C:

[Kevin B KENNY]

Logged In: YES
user_id=99768

It goes astray inside TclFSNormalizeAbsolutePath,
when presented with pathPtr designating the path
"C:/c:"

This function was rewritten between 8.4 and 8.5.

[Don Porter]

Logged In: YES
user_id=80530

Is the bug here really in Tcl_FSSplitPath() ?

Shouldn't it produce:

C:/ ./c:

according to the same spirit as:

% file split /~x
/ ./~x

on unix ?

[Don Porter]

Logged In: YES
user_id=80530

In SplitWinPath() (generic/tclFileName.c)
where elements beginning with ~ are
prefixed with ./ , we could also prefix with ./
any element that's not "relative" pathtype.

Wouldn't that fix this? Wouldn't that be
correct as well?

[Vince Darley]

Logged In: YES
user_id=32170

Apologies for not looking at this much -- been very busy!
(And sadly will be for the next few weeks).

Anyway, looking at this I'm beginning to think the best
approach would be to backport the 8.5 filesystem changes to
8.4. 8.5 has a much more robust handling of pwd/cd, and
fixes other bugs too (While some of these other fixes have
been backported to 8.4, not all have -- some are very hard
to do).

If not, we have to find a 'different' fix since the code is
so diverged in the two branches...

[Kevin B KENNY]

Logged In: YES
user_id=99768

dgp's change as described applies perfectly to both the HEAD
and 8.4.
It fixes the immediate problem my making [file split c:/c:d]
return {c:/ ./c:d} and putting the converse code into [file
join].
This change makes drive letters analogous to ~ syntax for user
names - meainingful only in the first component.

No new test failures occur with the bug fixed.