([from #1445](https://github.com/geany/geany/pull/1445#issuecomment-313235665))
On Windows (8.1 here), Geany has problems working with files whose full path, when encoded in UTF-8, takes up 260 or more bytes. Such a path is possible if it contains non-ASCII characters.
In particular:
- Geany silently refuses to open more than one such file, instead jumping to the first one, as if they were identical. - When such a file appears in the goto-symbol pop-up menu, its name is not shown. - When it is selected from such a pop-up, Geany correctly navigates to the file, but a message is printed to the console (if running with `--verbose`):
Geany: utils_tidy_path: assertion 'g_path_is_absolute(filename)' failed
Don't know if its relevant, but tagmanager `get_path_max()` which is used in `get_real_path()` is wrong, it checks a compile time symbol `PATH_MAX` and then uses the value on an unknown run time system [see](https://github.com/geany/geany/blob/35a5d457f48c92ecb71b5a2ecf7d718701d5ef63...)
At the very least it should use pathconf() all the time (does it work on windows?) but IIUC it gives a value "unsuitable for allocating memory" (ie very high, eg SIZE_MAX) on some systems.
Sigh. `PATH_MAX` is not our only problem here. `PATH_MAX` is actually 260, in case this wasn't known already before. In `src/win32.c` we also use the constant `MAX_PATH` which seems to be 260 as well.
But even with more than 260 (tried to trick 1024 into `get_path_max()`) doesn't help as it seems the `realpath()` in `src/tagmanager/tm_sourcefile.c` is broken for such paths. Maybe because we use `GetFullPathNameA()` here and do not pass properly encoded filenames. But this is just a guess. What I know so far after a little debugging is that `realpath()` returns an empty string for such filenames and those empty strings are compared with each other, hence only the first such file is opened because at the second file Geany things the file with the realpath `""` is already opened.
The comment on the `realpath()` function states it was just taken from a bug report. And the comment sounds a bit like as if I wrote it years ago :). Maybe nowadays there are better, more reliable ways to get a unique filename on Windows?
I won't debug this issue further for now as preparing the release is more important and fixing this issue takes probably more time than we have before the release. Anyway, any ideas are welcome!
From the docs for [GetFullPathName](https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).a...):
In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function (GetFullPathNameW), and prepend "\?" to the path.
I'm not sure why we use any ANSI functions in Win32 code, that stuff has been deprecated for nearly 20 years by now. We should just define `_UNICODE` or whatever and use the bare wrapper macros and `TCHAR` for character type.
Some time ago I wrote a portable, "proper" (not limited size) `realpath` kind of function, using `GetFullPathName()` on Windows, `canonicalize_file_name()` where supported, and `pathconf/realpath` on others, etc. If I get a chance I'll see if I can find it or re-implement it (it was fairly straightforward).
github-comments@lists.geany.org