Why would this be?
shell> ls -al "GrayWhale\\simulations\\gw_fs_fluid_damping=1_forcing_type=approx_acoustic_pressure_meshnum=8_neigvs=2200_sweep=full25\\gw_fs_fluid_damping=1_forcing_type=approx_acoustic_pressure_meshnum=8_neigvs=2200_sweep=full25.json"
-rw-r--r-- 1 pkonl 197609 24917 Aug 12 10:43 'GrayWhale\simulations\gw_fs_fluid_damping=1_forcing_type=approx_acoustic_pressure_meshnum=8_neigvs=2200_sweep=full25\gw_fs_fluid_damping=1_forcing_type=approx_acoustic_pressure_meshnum=8_neigvs=2200_sweep=full25.json'
On Windows 10.
open call also fails.
Could it be windows “powershell long filename issue”?
"gw_fs_fluid_damping=1_forcing_t" ⋯ 37 bytes ⋯ "8_neigvs=2200_sweep=full25.json"
"gw_fs_fluid_damping=1_forcing_t" ⋯ 36 bytes ⋯ "=8_neigvs=2200_sweep=full25.log"
It would appear that Windows 10 has a limit on the length of the name of each individual file of 92 characters (plus extension). That is based purely on experimentation, I couldn’t find any documentation.
The “cc…cc” file name is of acceptable length, the others are too long.
This filename is 216 characters, which is starting to get close to the 260-character limit on pathnames in the Win32 API. Maybe something internally is expanding your relative path to an absolute path or a realpath (e.g. expanding symlinks) and is hitting that limitation.
isfile(path) just calls
uv_fs_stat from libuv. What does
stat return on this path? If that’s not working, it may be a limitation of libuv.
It appears to be an OS limitation on the length of the individual file path component (those 92 characters).
I’ve never heard of such a limit on individual files in Windows. The only limit I can find mentioned anywhere online is on total path lengths. It’s more plausible to me that if your file length is sufficiently long, then you are hitting the
To test this, try moving the file into a folder with a shorter name.
You may be right, it could be that I was not able to make the individual file name longer
because the file explorer counted all the characters in the absolute path. Which means that the relative path
length was immaterial, because the system always used the limit on the absolute path.
\\?\ to the path work?
Also describes how to disable the path check altogether on Windows 10/11.
I think that did not work.
I don’t think you can mix slash directions.
Good point, still no cigar.
I’ve seen it said many times on this forum that Julia aims for correctness…but I have not yet seen any such guarantees about truthfulness
This path is 262 characters long, which is longer than the Windows
640k and 260 characters ought to be enough for anybody, no?
But: notice the
\\?\. That is expected to allow longer file paths. Oh well, not the first thing not to work on Windows.
By the way, I set
LongPathsEnabled in the registry, to no avail.
So now I am switching over to WSL 2. Windows is a best in class operating system? My foot!
Oh, I think based on the documentation each application also needs to opt-in to supporting it.
But Julia itself seems to do that: julia/julia-manifest.xml at master · JuliaLang/julia · GitHub
libuv seems to as well
Did you reboot the machine after doing so?