Tcl Source Code: View Ticket

2026-03-25
04:11		Merge 9.0. Bug [b0682c3c24]. Windows Glob error with drive in pattern check-in: 6cd2936408 user: apnadkarni tags: trunk, main
03:31		• Closed ticket [b0682c3c24]: glob error plus 6 other changes artifact: ca18c9cc2d user: apnadkarni
03:29		Bug [b0682c3c24]. Windows Glob error with drive in pattern check-in: 874e86e528 user: apnadkarni tags: core-9-0-branch
2026-03-18
16:20		• Ticket [b0682c3c24] glob error status still Open with 3 other changes artifact: 19d58ec013 user: apnadkarni
16:04		• Ticket [b0682c3c24]: 4 changes artifact: 30f75b7c06 user: apnadkarni
11:38		Start on bug [b0682c3c24]. glob errors on Windows check-in: 52f35167af user: apnadkarni tags: bug-b0682c3c24
2025-11-14
13:22		• Ticket [b0682c3c24] glob error status still Open with 3 other changes artifact: aa2a0c3ed2 user: anonymous
07:48		• Ticket [b0682c3c24]: 3 changes artifact: 58497f4248 user: anonymous
2025-10-07
15:31		• Ticket [b0682c3c24]: 3 changes artifact: 745924f882 user: dkf
2025-09-25
16:31		• Ticket [b0682c3c24]: 3 changes artifact: a4c316b177 user: juliannoble2
12:52		• Ticket [b0682c3c24]: 3 changes artifact: e3e8fccf7d user: anonymous
2025-07-21
19:15		• Ticket [b0682c3c24]: 3 changes artifact: a32b0ae555 user: sebres
2025-06-10
09:40		• New ticket [b0682c3c24]. artifact: ea513ab823 user: anonymous

Ticket UUID:	b0682c3c2497e8f27f18e91686031dda055ed19c
Title:	glob error
Type:	Bug	Created on:	2025-06-10 09:40:06
Submitter:	anonymous	Assigned to:	nobody
Subsystem:	37. File System	Severity:	Important
Priority:	5 Medium	Last modified:	2026-03-25 03:31:11
Status:	Closed	Closed by:	apnadkarni
Resolution:	Fixed	Closed on:	2026-03-25 03:31:11
Version:	9.0.0 9.0.1

Description:
I have the following strange behaviour under Windows 10 with tcl_patchLevel=9.0.0 (and tcl_patchLevel=9.0.1 from BAWT) (bin) 1 % set tcl_patchLevel 9.0.0 (bin) 2 % glob Z:/Basistests/200* Z:/Basistests/2000_00_00 {Z:/Basistests/2000_00_00 - Test} (bin) 3 % glob -types d Z:/Basistests/200* Z:/Basistests/2000_00_00 {Z:/Basistests/2000_00_00 - Test} (bin) 4 % glob -types d -directory Z:/Basistests -tails Z:/Basistests 200* Z:Basistests 2000_00_00 {2000_00_00 - Test} (bin) 5 % glob -types d -directory Z:/Basistests -tails Z:/Basistests Z:/Basistests/200* couldn't read directory "Z:/Basistests/Z:Basistests/200": not a directory Under tcl8 I got: (ABS) 1 % glob -types d -directory Z:/Basistests -tails Z:/Basistests 200 2000_00_00 {2000_00_00 - Test} (ABS) 2 % glob -types d -directory Z:/Basistests -tails Z:/Basistests Z:/Basistests/200* no files matched glob patterns "Z:/Basistests Z:/Basistests/200" The additional string "Z:Basistests" on comcd mand 4 is wrong. Even more perplexing is the following (under Tcl/Tk 9.0.0): (ABS) 1 % glob -types d -directory Z:/Basistests -tails Z:/Basistests 200 Z:Basistests 2000_00_00 {2000_00_00 - Test} (ABS) 2 % cd Z:Basistests (Basistests) 3 % pwd Z:/Basistests (Basistests) 4 % cd C: () 5 % cd Z:Basistests (Basistests) 6 % cd 2000_00_00 (2000_00_00) 7 % cd Z:Basistests couldn't change working directory to "Z:Basistests": no such file or directory (2000_00_00) 8 %
User Comments:
sebres added on 2025-07-21 19:15:09: If I understand it correctly (please provide short "diff", what is expected and what is wrong result), it may be a side effect of bug [61c01e0edb08a9ed], because looks really similar to us. If so it shall be fixed now. Please test again with the fixed version. anonymous added on 2025-09-25 12:52:31: Still the same under tcl 9.0.2 :( juliannoble2 added on 2025-09-25 16:31:19: I also see this on a recent 9.0.2 build Paths such as Z:Basistests are volume-relative Tcl doesn't support the per-volume cwd - there are long-standing bugs in this area when changing drives in Tcl as compared to what happens in cmd.exe or powershell. If you cd to Z:/Basistests for command 4 - you will see the Z:basistests entry is no longer present in the result. for command 5 - the 'couldn't read directory' error is not raised. glob with the -directory option, and no specific reference to volume-relative paths shouldn't change output based on the cwd. (and shouldn't return any volume relative paths) I've argued in a previous ticket that it may be worth considering removing volume-relative path support. I'd really prefer it was supported - but there are still footguns regarding the cd command and comparing glob output to external tools/commands view of things due to the occasional difference in ideas of what is the actual current working directory for a drive. The example given above of cd c: & cd Z:Basistests can be a problem with tcl8 too - as it can depend on what directory you were in when starting tclsh. Perhaps in this case we can at least make glob handle things better, even if a full fix-up of the volume-relative path problems isn't something anyone is able to delve into now. anonymous added on 2025-11-14 07:48:15: It seems the error is gone in tcl9.0.3. anonymous added on 2025-11-14 13:22:37: Sorry, the error gone in tcl9.0.3 is not true :( The strange Z:Basistests still exists. apnadkarni added on 2026-03-18 16:04:36: Potential fix in the bug-b0682c3c24 branch. But see below. `% glob d:/Basistests/200* d:/Basistests/2000_00_00 {d:/Basistests/2000_00_00 - Test} % glob -types d d:/Basistests/200* d:/Basistests/2000_00_00 {d:/Basistests/2000_00_00 - Test} % glob -types d -directory d:/Basistests -tails d:/Basistests 200* 2000_00_00 {2000_00_00 - Test} % glob -types d -directory d:/Basistests -tails d:/Basistests d:/Basistests/200* %` which seems reasonable to me. The cd issues in the original ticket I didn't quite understand as it seems to be it depends on what the "current directory" on the other drive happened to be. In the existing implementation, glob correctly parses the `-directory` and pattern into components `d:/basictests`, `d:` and `basictests`. However when checking for existence, the implementation invokes `Tcl_FSTranslatePath` which reparses the path by calling `TclJoinPath` which behaves as the script level `join` command which discards any components prior to anything an absolute or volume-relative component. In this case `d:` is the volume relative component so the existence check is made against "d:Basictests". The result will then depend on whether the "current directory" on drive D: is the root or not. As a fix, it seems to me that `Tcl_FSGetTranslatedPath` is broken in this behaviour. Not only is this "join-like" behaviour mentioned anywhere in the documentation, I also think it does not make semantic sense. The function is supposed to translate a single path and should not be discarding any components. In particular on Unix, it already behaves this way by not treating a leading `/` in a pattern as an absolute path. `% glob -directory /tmp /foo /tmp/foo` I therefore consider this as a bug fix and not a change to defined or expected `Tcl_FSGetTranslatedPath` behavior (which would require a TIP). Opinions? apnadkarni added on 2026-03-18 16:20:36: Regarding the cd issue, I've logged [bca391ab51] as a separate issue. May be that is what the ticket was referring to. apnadkarni added on 2026-03-25 03:31:11: Fixed in [874e86e528].