OK, bug #57215.

This isn't really related to the change for this bug report. Maybe it would be better to have a dedicated bug number...

I used the prefix "\\?\" to remove the MAX_PATH limitation [1].
However, this seems to work with absolute paths only.

The following change should fix it:

diff -r e8e7ec705418 liboctave/util/kpse.cc
--- a/liboctave/util/kpse.cc        Wed Nov 06 20:07:55 2019 +0100
+++ b/liboctave/util/kpse.cc        Tue Nov 12 21:58:14 2019 +0100
@@ -169,7 +169,7 @@
 {
 #if defined (OCTAVE_USE_WINDOWS_API)

-  std::wstring w_fn = L"\\\\?\\" + octave::sys::u8_to_wstring (fn);
+  std::wstring w_fn = octave::sys::u8_to_wstring (fn);

   DWORD f_attr = GetFileAttributesW (w_fn.c_str ());

I'll try to cross-build before I commit.

[1]: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesa

Did I just hit another manifestation of this bug? (it doesn't seem to canonicalize "."). If not I'll open a new bug report.

See attached pic, where "which" can find curr_prefix.m but the editor can't.

OK, all paths in the output of "path" are now LFN, good & thanks.

That brings up a second question:
I now some some very long paths listed:

:
:
L:\philip\devel\octdev\mxe\mxe_64w_20190901\dist\octave\mingw64\share\octave\6.0.0\m\testfun
L:\philip\devel\octdev\mxe\mxe_64w_20190901\dist\octave\mingw64\share\octave\6.0.0\m\time
L:\philip\devel\octdev\mxe\mxe_64w_20190901\dist\octave\mingw64\share\octave\6.0.0\m\web
L:\philip\devel\octdev\mxe\mxe_64w_20190901\dist\octave\mingw64\share\octave\6.0.0\data

>> OCTAVE_HOME
ans = L:\philip\devel\octdev\mxe\mxe_64w_20190901\dist\octave\mingw64
>>

(in case you wonder, L: is my Linux /home partition mounted in windows using ext2fsd)

I'm wondering if there's any support for shortening those by using e.g., <OCTAVE_HOME> as first entry, so the listing could be

:
:
<OCTAVE_HOME>\share\octave\6.0.0\m\testfun
<OCTAVE_HOME>\share\octave\6.0.0\m\time
<OCTAVE_HOME>\share\octave\6.0.0\m\web
<OCTAVE_HOME>\share\octave\6.0.0\data
>>

m-file example code to get this together is in my pending patch for bug #51632, second hunk for private/installed_packages.m.
For load-path.cc it obviously needs translation to C++.

Could be a new bug report / feature request. Shall I open one?

@Markus:
Your fix works fine, thanks.
I tried the examples in my original report in various combinations of case and fileseps but Octave won't get fooled anymore, I only get one instance of the subdir in question in the path.
Fine, so this bug can be closed I think.

Just as a side note, I've hit issues with it that seemed unrelated at first.

On Windows, 8.3 style path names are used to make Octave cope with spaces in path names. Your patch morphs these 8.3 style path names into LFN (long file name) path names and it now turns out that pkg.m is subsequently affected by a mixup of 8.3 and LFN path names.
Further discussion of those effects are in bug #57083, as I think pkg.m needs adaptation and your big fix here is what needed to be done.

Found the error and applied the two patches here:
http://hg.savannah.gnu.org/hgweb/octave/rev/def608acdfa9
http://hg.savannah.gnu.org/hgweb/octave/rev/5a0543de1e47

Marking as ready for test.

The attached patch canonicalizes the path before adding it to the search path in addpath. It should be applied on top of file #47568.

@Rik: Is this the kind of modification to addpath you were thinking about?

(file #47632)

With the attached path, I see the following on Windows 10 64bit:

>> canonicalize_file_name ('C:\WINDOWS')
ans = C:\Windows
>> canonicalize_file_name ('C:\WINDOWS\SYSTEM32')
ans = C:\Windows\System32
>> canonicalize_file_name ('c:\WiNdOwS/SYSWOW64')
ans = c:\Windows\SysWOW64

It doesn't work for UNC paths though. However, I don't know whether we are supporting these anyway.

It also doesn't change the case of the drive letter. Maybe we should always return a capital letter?

I am also not sure whether it is OK to conditionally include windows.h in the core file.

Octave 6 crashes when running the test suite (with and without the patch). Therefore, it is hard to judge whether it is save to apply this change. The tests that were running until the crash looked ok.

(file #47557)

Enjoy your, I hope, vacation.  Can take this up later.

If it does a verbatim copy then canonicalize_file_name handles only the file separator part of the duplication.  But it would still be possible to add two equivalent directory with different cases

addpath ('C:\USERS')
addpath ('C:\Users')
path

I checked on the code in javaclasspath.m and it is:

for i = 1:numel (varargin)
  clspath = varargin{i};
  if (! ischar (clspath))
    error ("javaaddpath: CLSPATH must be a string");
  endif

  new_path = canonicalize_file_name (tilde_expand (clspath));
  if (isfolder (new_path))
    if (new_path(end) != filesep ())
      new_path = [new_path, filesep()];
    endif
  elseif (! exist (new_path, "file"))
    error ("javaaddpath: CLSPATH does not exist: %s", clspath);
  endif

  success = javaMethod ("addClassPath", "org.octave.ClassHelper", new_path);

So, just as suspected, it calls canonicalize_file_name to make the name standard before adding it to the path, and that standardization eliminates the duplicates that differ by file separator.

Does canonicalize_file_name also handle case?

What does this return on Windows?

canonicalize_file_name ('C:\USERS\PHILIP')

In Octave, what does this return?

canonicalize_file_name ('C:/Users/Philip')
canonicalize_file_name ('C:\Users\Philip')

If they return the same string then we could add a call to canonicalize_file_name in addpath before checking whether a path is a duplicate.