From Newsgroup: comp.lang.tcl

It is known that Windows has a maximum path length of round about 260
chars for files and directories.

Interestigly Tcl can define files with longer paths and work with those without issues.

I discovered an issue though when using tk_getOpenFile to choose such a
file. The function returns a path that is shortened by the OS by
replacing lots of chars in the path by ~.

I wonder if there is a way to get the original path back after using tk_getOpenFile.

Many thanks
Alex


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* meshparts <alexandru.dadalau@meshparts.de>
| It is known that Windows has a maximum path length of round about 260
| chars for files and directories.

| Interestigly Tcl can define files with longer paths and work with
| those without issues.

| I discovered an issue though when using tk_getOpenFile to choose such
| a file. The function returns a path that is shortened by the OS by
| replacing lots of chars in the path by ~.

| I wonder if there is a way to get the original path back after using
| tk_getOpenFile.

Check the -longname and -shortname attributs of [file]:

https://www.tcl-lang.org/man/tcl9.0/TclCmd/file.html#M8

file attributes name ?option value option value...?
On Windows, [...] -longname will expand
each path element to its long version. This attribute cannot be
set. [...] -shortname gives a string where every
path element is replaced with its short (8.3) version of the
name.

Don't know whether this applies here.
Does the (short) filename returned by tk_getOpenFile work to access the file?

R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 26.11.2025 um 17:26 schrieb Ralf Fassel:

Check the -longname and -shortname attributs of [file]:

Wonderful! Thank you for the fast help.
I works.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 26.11.2025 um 17:26 schrieb Ralf Fassel:

Does the (short) filename returned by tk_getOpenFile work to access the file?

No, it doesn't work with the short version in Tcl.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 26.11.2025 um 18:17 schrieb meshparts:

Am 26.11.2025 um 17:26 schrieb Ralf Fassel:

Does the (short) filename returned by tk_getOpenFile work to access
the file?

No, it doesn't work with the short version in Tcl.

Then, this is a bug.
Do you have an example what exactly does not work ?

Thanks,
Harald
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 27.11.2025 um 08:09 schrieb Harald Oehlmann:

Then, this is a bug.
Do you have an example what exactly does not work ?

I don't have an example, but the process should be simple:
1. Create a long hierarchical directory structure that contains just
about 200 chars
2. Create in the deepest directory a file with more than 60 char. The extension of the file was in my case .Omega.
3. Retrieve the file path using tk_getOpenFile in a variable
4. Try to read the content of the file using that path. Alternativelly
check if the file exists.

Regards
Alex



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 11/27/2025 8:04 AM, meshparts wrote:

Am 27.11.2025 um 08:09 schrieb Harald Oehlmann:

Then, this is a bug.
Do you have an example what exactly does not work ?

I don't have an example, but the process should be simple:
1. Create a long hierarchical directory structure that contains just
about 200 chars
2. Create in the deepest directory a file with more than 60 char. The extension of the file was in my case .Omega.
3. Retrieve the file path using tk_getOpenFile in a variable
4. Try to read the content of the file using that path. Alternativelly
check if the file exists.

Did you try this yourself? Because Windows does not let you go beyond
the 256 character limit in a file path anyways.


On Windows 11, 64bit:

From Windows file explorer, when you create two nested folders where he
path reches the limit, it shows an error box with title "Destination
Path Too Long" where it says "The file name(s) would be too long..."



From Tcl:

% set name [string repeat a 130]
% cd c:/

This is OK:

% file mkdir $name
% cd $name


Path longer than the limit:

% file mkdir $name
can't create directory "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa":
no such file or directory





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 28.11.2025 um 15:02 schrieb saito:

Did you try this yourself?  Because Windows does not let you go beyond
the 256 character limit in a file path anyways.

Well, yes. Though my software.
The user can create folders in an integrated file explorer.
Then some processing is started and new folders and files are created automatically.
When the user then tries to select that long name file, the
tk_getOpenFile returns that short name instead.
When the software tries to read that file, it can't.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 26.11.2025 um 17:15 schrieb meshparts:

It is known that Windows has a maximum path length of round about 260
chars for files and directories.

Interestigly Tcl can define files with longer paths and work with those without issues.

I discovered an issue though when using tk_getOpenFile to choose such a file. The function returns a path that is shortened by the OS by
replacing lots of chars in the path by ~.

I wonder if there is a way to get the original path back after using tk_getOpenFile.

Many thanks
Alex

Ok, it's a mess!
Now I get feedback from another customer, that tk_getOpenFile fails when special chars are involved in the file path name!
If I remove the -longpath option, it works again.
I need a solution for this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 08:49 schrieb meshparts:

Am 26.11.2025 um 17:15 schrieb meshparts:

It is known that Windows has a maximum path length of round about 260
chars for files and directories.

Interestigly Tcl can define files with longer paths and work with
those without issues.

I discovered an issue though when using tk_getOpenFile to choose such
a file. The function returns a path that is shortened by the OS by
replacing lots of chars in the path by ~.

I wonder if there is a way to get the original path back after using
tk_getOpenFile.

Many thanks
Alex

Ok, it's a mess!
Now I get feedback from another customer, that tk_getOpenFile fails when special chars are involved in the file path name!
If I remove the  -longpath  option, it works again.
I need a solution for this.

I looked deepr into the source code.
The "open" command fails when that path is converted into longname.
Other file related commands seem to work.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.12.2025 um 08:56 schrieb meshparts:

Ok, it's a mess!
Now I get feedback from another customer, that tk_getOpenFile fails
when special chars are involved in the file path name!
If I remove the  -longpath  option, it works again.
I need a solution for this.

I looked deepr into the source code.
The "open" command fails when that path is converted into longname.
Other fi

I have this temporary fix, that seem to work:

# Try to fix a path when file paths are longer than 260 chars which
will force the OS to return short path names using ~
if {[string first ~ $path]>=0} {
set path [file attributes $path -longname]
}

So the fix is active only when the path is indeed too long.
It will probably fail if the path also contains special chars when
"open" is applied on this path.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/2025 2:46 AM, meshparts wrote:

Well, yes. Though my software.

I am afraid I'm still confused. If the OS doesn't let you do it, how is
your software, running on that OS, able to do it?

The user can create folders in an integrated file explorer.
Then some processing is started and new folders and files are created automatically.

So, you are creating a "logical" file hierarchy of sorts in your
application.

When the user then tries to select that long name file, the
tk_getOpenFile returns that short name instead.
When the software tries to read that file, it can't.

OK, this now makes sense because your logical hierarchy doesn't nicely
map to the capabilities of the OS.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 12/1/2025 3:09 AM, meshparts wrote:

I have this temporary fix, that seem to work:

    # Try to fix a path when file paths are longer than 260 chars which will force the OS to return short path names using ~
    if {[string first ~ $path]>=0} {
      set path [file attributes $path -longname]
    }

So the fix is active only when the path is indeed too long.
It will probably fail if the path also contains special chars when
"open" is applied on this path.

Just an FYI, the tilde (~) is an allowed character in Windows file and
folder names. It doesn't always mean "file path shortened by Windows".
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.12.2025 um 16:07 schrieb saito:

On 12/1/2025 2:46 AM, meshparts wrote:

Well, yes. Though my software.

I am afraid I'm still confused. If the OS doesn't let you do it, how is
your software, running on that OS, able to do it?

Don't know. It somehow works.
Probably because the folder path is shorter than 260 chars.
When my aplication defines file in the folder, the file names are so
long, that the total file path is larger than 260.

The user can create folders in an integrated file explorer.
Then some processing is started and new folders and files are created
automatically.

So, you are creating a "logical" file hierarchy of sorts in your application.

I don't know what "logical" file hierarchy is.
But the folders are ultimatelly defined in the Windows file system.

When the user then tries to select that long name file, the
tk_getOpenFile returns that short name instead.
When the software tries to read that file, it can't.

OK, this now makes sense because your logical hierarchy doesn't nicely
map to the capabilities of the OS.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.12.2025 um 16:12 schrieb saito:

ust an FYI, the tilde (~) is an allowed character in Windows file and
folder names.  It doesn't always mean "file path shortened by Windows".

Yes, I know.
It's just that Tcl has a problem with this tilde in the "open" command,
when the total file path length is over 260 I guess. Maybe it has also something to do with the special char in the path name.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* meshparts <alexandru.dadalau@meshparts.de>
| Am 02.12.2025 um 16:07 schrieb saito:
| > On 12/1/2025 2:46 AM, meshparts wrote:
| >
| >> Well, yes. Though my software.
| > I am afraid I'm still confused. If the OS doesn't let you do it, how
| > is your software, running on that OS, able to do it?

| Don't know. It somehow works.
| Probably because the folder path is shorter than 260 chars.
| When my aplication defines file in the folder, the file names are so
| long, that the total file path is larger than 260.

Probably it would be best if you could show that part of your code where
you create the files (stripped down so that one can try it).
How many directory levels are involved? Many short-named subdirs, or
few long-named subdirs, or mix of both?

No matter how I try, I alway get an error when creating a too-long
filename, regardless where I try it (cmd.exe, Windows explorer, TCL).

I could create a >260 chars filename on Linux and then mount that share
to Windows, but since you say the files are created locally, I assume
that the file system is NTFS locally on Windows?

R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.12.2025 um 20:26 schrieb Ralf Fassel:

* meshparts <alexandru.dadalau@meshparts.de>
| Am 02.12.2025 um 16:07 schrieb saito:
| > On 12/1/2025 2:46 AM, meshparts wrote:
| >
| >> Well, yes. Though my software.
| > I am afraid I'm still confused. If the OS doesn't let you do it, how
| > is your software, running on that OS, able to do it?

| Don't know. It somehow works.
| Probably because the folder path is shorter than 260 chars.
| When my aplication defines file in the folder, the file names are so
| long, that the total file path is larger than 260.

Probably it would be best if you could show that part of your code where
you create the files (stripped down so that one can try it).
How many directory levels are involved? Many short-named subdirs, or
few long-named subdirs, or mix of both?

No matter how I try, I alway get an error when creating a too-long
filename, regardless where I try it (cmd.exe, Windows explorer, TCL).

I could create a >260 chars filename on Linux and then mount that share
to Windows, but since you say the files are created locally, I assume
that the file system is NTFS locally on Windows?

R'

Perhaps this one:

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Remark, that longPathAware is not in tclsh manifest in 8.6 and 9.0

I also remeber a lot of tickets on this.
In most cases, a newer API was used.

Perhaps it is incomplete.

Take care,
Harald
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.12.2025 um 20:26 schrieb Ralf Fassel:

I could create a >260 chars filename on Linux and then mount that share
to Windows, but since you say the files are created locally, I assume
that the file system is NTFS locally on Windows?

That's a yes.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.12.2025 um 20:26 schrieb Ralf Fassel:

Many short-named subdirs, or
few long-named subdirs, or mix of both?

This is the kind of path that causes the bug:

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...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.12.2025 um 22:35 schrieb meshparts:

Am 02.12.2025 um 20:26 schrieb Ralf Fassel:

Many short-named subdirs, or
few long-named subdirs, or mix of both?

This is the kind of path that causes the bug:

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

We need a Tk ticket for this, as the initial issue it tk_getFile.
I may take care.
Give me some time...

Harald
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* meshparts <alexandru.dadalau@meshparts.de>
| Am 02.12.2025 um 20:26 schrieb Ralf Fassel:
| > Many short-named subdirs, or
| > few long-named subdirs, or mix of both?
| This is the kind of path that causes the bug:

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

Duh... In my case it works in TCL/wish 8.6.17 / Windows 11:

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

So no error accessing the file via short or long name...

Interestingly when trying to remove the directory from msys shell:

$ rm -rf /c/data
rm: cannot lstat `/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': File or path name too long

Windows explorer can remove the directory hierarchy without problems.

R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* 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'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 05.12.2025 um 17:08 schrieb Harald Oehlmann:

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

I reproduced it on Tcl 8.6 and 9.0.

Ticket is here:

https://core.tcl-lang.org/tk/tktview/e3e32831781381c0d84efc9ab8b185e024c41990

Thanks,
Harald
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 05.12.2025 um 17:27 schrieb Harald Oehlmann:

I reproduced it on Tcl 8.6 and 9.0.

Ticket is here:

https://core.tcl-lang.org/tk/tktview/ e3e32831781381c0d84efc9ab8b185e024c41990

Thanks,
Harald

Great! Thanks.
Even if my bug could not be reproduced, it will help when fixed..
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* 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'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* 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'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 08.12.2025 um 15:11 schrieb Ralf Fassel:

* 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'

Please give me some time. The "long path" issues were all handled in the
past in TCL. Probably, this part located in Tk was overlooked.
There might be just an option necessary to the used system COM object.

Thanks,
Harald
--- Synchronet 3.21a-Linux NewsLink 1.2