Am 02.12.2025 um 20:26 schrieb Ralf Fassel:
Many short-named subdirs, orThis is the kind of path that causes the bug:
few long-named subdirs, or mix of both?
Folder structure:
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 name in that folder:
250807-1234-Konzept_Palette_in_Y- Richtung_V2_Modal_Traeger_F600mm_Y0_all_closed.Omega
My app creates this file with:
set code [catch {set fid [open $path w]} err]
Then tries to read the content of the file with:
set code [catch {set fid [open $path r]} err]
The result is:
couldn't open "C:/Data/1234567/99_MES~1/MESHPA~1/ASSEMB~1/1234567/ MASCHI~1/12345678/KONZEP~1/VARAIN~1/250807~1/250807~1.Omega": no such
file or directory
I just realized, that the file can be created because in that case the
app uses the long file name.
The issue is when the user selects the file using tk_getOpenFile which
will return the short name.
Should be easy to reproduce...
* Ralf Fassel <ralfixx@gmx.de>
| 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/"
Something messed up the line breaks in my posting, this is all one
single line, with single spaces where there are newlines in the "".
../Varainte 3 Y-RIchtung 2040/...
R'
Am 05.12.2025 um 16:39 schrieb Ralf Fassel:
* Ralf Fassel <ralfixx@gmx.de>
| 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/"
Something messed up the line breaks in my posting, this is all one
single line, with single spaces where there are newlines in the "".
../Varainte 3 Y-RIchtung 2040/...
R'
Thanks, Ralf, I appreciate.
I remember, that this story is constantly handled.
Aparently, TCL is good and accepts the long and short file.
Due to that, the tk_getOpenFile may directly return the long file name.
Thanks for testing,
Harald
So no error accessing the file via short or long name...Well in my case it#s an error, like aready said.
I reproduced it on Tcl 8.6 and 9.0.Great! Thanks.
Ticket is here:
https://core.tcl-lang.org/tk/tktview/ e3e32831781381c0d84efc9ab8b185e024c41990
Thanks,
Harald
* meshparts <alexandru.dadalau@meshparts.de>Yes, I aware of this setting. But on my system it's deactivated HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled = 0
| Am 05.12.2025 um 16:36 schrieb Ralf Fassel:
| > So no error accessing the file via short or long name...
| Well in my case it#s an error, like aready said.
| But maybe it's somehow related to Tcl 9 then...
This site on MSDN has more on the topic:
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
It seems there are numerous ways to avoid the 260-char-length limit, depending on the API in use, the registry (and maybe also the phase of
the moon, as usual on Windows ;-)
NB. The registry value mentioned in the article is "0" on my Windows machine.
R'
* meshparts <alexandru.dadalau@meshparts.de>
| Am 08.12.2025 um 11:25 schrieb Ralf Fassel:
| > * meshparts <alexandru.dadalau@meshparts.de>
| > | Am 05.12.2025 um 16:36 schrieb Ralf Fassel:
| > | > So no error accessing the file via short or long name...
| > | Well in my case it#s an error, like aready said.
| > | But maybe it's somehow related to Tcl 9 then...
| > This site on MSDN has more on the topic:
| > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
| > It seems there are numerous ways to avoid the 260-char-length limit,
| > depending on the API in use, the registry (and maybe also the phase of
| > the moon, as usual on Windows ;-)
| > NB. The registry value mentioned in the article is "0" on my Windows
| > machine.
| > R'
| Yes, I aware of this setting. But on my system it's deactivated
| HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
| LongPathsEnabled = 0
Since the registry alone would not help - the app also needs to opt-in
via the .exe manifest - I think this is rarely used (?).
Plus from looking at the source, TCL seems to go the "\\?\" prefix way
for long file names anyway (cf. TclNativeCreateNativeRep() in win/tclWinFile.c), which works without registry fiddling:
/*
* If there is no "\\?\" prefix but there is a drive or UNC path prefix
* and the path is larger than MAX_PATH chars, no Win32 API function can
* handle that unless it is prefixed with the extended path prefix. See:
* <https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maxpath>
*/
[code that adds the \\?\ prefix for long pathnames > PATH_MAX]
I *think* this means that if tk_getOpenFile returns a long path, TCL
itself would probably handle it ok, but any other application which is
passed that filename would fail if it does not go the same path
(no pun intended :-).
R'
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,113 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492339:09:16 |
| Calls: | 14,239 |
| Calls today: | 1 |
| Files: | 186,312 |
| D/L today: |
4,353 files (1,412M bytes) |
| Messages: | 2,514,942 |