Tk Source Code: View Ticket

Ticket UUID:	e3e32831781381c0d84efc9ab8b185e024c41990
Title:	MS-Win: tk_getOpenFile returns short path, if path is longer than 256 characters
Type:	Bug	Version:	main to 8.6
Submitter:	oehhar	Created on:	2025-12-05 16:26:37
Subsystem:	37. [tk_get*File]	Assigned To:	nobody
Priority:	5 Medium	Severity:	Minor
Status:	Open	Last Modified:	2026-09-18 11:39:59
Resolution:	None	Closed By:	nobody
		Closed on:
Description:	A current thread "Handling of long paths in Tcl and Windows 11" remarkt, that "tk_getOpenFile" returns a short path, if the choosen path is to long. A log is here: set dir "C:/Data/1234567/99_Meshparts/Meshparts-Offline/Assemblies/1234567/Maschinen/12345678/Konzeptstudien/Varainte 3 Y-RIchtung 2040/250807-1234-Konzept_Palette_in_Y-Richtung_V2_Modal_Traeger_F600mm_Y0_all_closed_msup/" file mkdir $dir cd $dir set file "250807-1234-Konzept_Palette_in_Y-Richtung_V2_Modal_Traeger_F600mm_Y0_all_closed.Omega" set path [file join $dir $file] set code [catch {set fid [open $path w]} err] => code 0 set code [catch {set fid [open $path r]} err] => code 0 set sfile [tk_getOpenFile] => C:/Data/1234567/99_MES~1/MESHPA~1/ASSEMB~1/1234567/MASCHI~1/12345678/KONZEP~1/VARAIN~2/250807~1/250807~1.OME set code [catch {set fid [open $sfile r]} err] => code 0 file attrib $sfile -longname => C:/Data/1234567/99_Meshparts/Meshparts-Offline/Assemblies/1234567/Maschinen/12345678/Konzeptstudien/Varainte 3 Y-RIchtung 2040/250807-1234-Konzept_Palette_in_Y-Richtung_V2_Modal_Traeger_F600mm_Y0_all_closed_msup/250807-1234-Konzept_Palette_in_Y-Richtung_V2_Modal_Traeger_F600mm_Y0_all_closed.Omega string equal $path [file attrib $sfile -longname] => 1 The returned file name is "C:/Data/1234567/99_MES~1/MESHPA~1/ASSEMB~1/1234567/MASCHI~1/12345678/KONZEP~1/VARAIN~2/250807~1/250807~1.OME". It would be more beautiful, if the long name would be returned. Specially, TCL has no issue with long names. Harald Credits: Alexander Dadalau for reporting Ralf Fassel for reproducing
User Comments:	serhiy.storchaka added on 2026-09-18 11:39:59: Verified on Windows 11 with a main build (which has `longPathAware` in the manifest since [ff2a261e8d]): with `LongPathsEnabled=1` in the registry the full long path is returned; with `LongPathsEnabled=0` the short path is returned as reported. So this is fixed in 9.1, but requires long paths to be enabled in the system. jan.nijtmans added on 2025-12-18 13:27:27: > I suppose, that the longpath attribute in the manifest of commit [0a9902c8128830e1] is also needed for TCL Wrong. The manifest in the *.exe is what counts. (but the longpath fixes in Tcl will need the manifest change in tclsh.exe, so eventually the manifest change will be done in both Tcl and Tk anyway) oehhar added on 2025-12-18 12:12:26: I suppose, that the lonpath attribute in the manifest of commit [0a9902c8128830e1] is also needed for TCL. apnadkarni added on 2025-12-18 11:20:14: See this Tcl ticket for systems where `apn-win-longpaths` may help and systems where it will not. With respect to Tk, I have not gotten around to it yet, but places that use static MAX_PATH arrays have to be reviewed. Additionally `tk_getOpenFile` etc. use Tcl native COM based dialogs. I am not sure if these have been updated by Microsoft to support longer paths. That will also have to be looked at. oehhar added on 2025-12-16 16:22:53: Yes, I appreciate Ashoks work. In my head, we had solved all long path issues in TCL. I was wrong. Sorry for that, Harald jan.nijtmans added on 2025-12-16 16:05:01: Acually, Tcl _has_ issues with long paths, it looks like those are being solved in the "apn-win-longpaths" branch. My guess is that Tk will follow with the same kind of fixes. Am I right, @ashok? Specifying a long path is never a problem. Getting them back from some API's is not always handled well. tk_getOpenFile() is another example of the same type.