No further comments for 2 weeks.  Okay to close report as Fixed?

just noting that in some older versions of either Octave or Windows (I can't remember specifically which) CMD cannot handle UNC paths. This used to be a problem in Octave and I had mapped certain network shares to drive letters to get around this. The expectation was that once something was mapped to a drive letter one would no longer see the UNC path under any typical usage.

issue highlighted here (but not really explaining which versions it's relevant in):
https://stackoverflow.com/questions/45071585/cmd-does-not-support-unc-paths-as-current-directories

Thanks for checking again.

For future reference (to self): It is not `__wglob__` that has changed behavior with mapped network drives (like I erroneously claimed before). But it is `canonicalize_file_name` which returns a UNC path now.

That was probably this changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/d7223245d26f

Re-reading: Does `load` and `csvread` not work with UNC paths?

I apologize for the imprecision. It provides the server and the share, my example was oversimplified.

It provides

ans = \\The_network_drive\share

I am not versed in the underlying mechanisms of dir(), but I know this new behavior causes problems for us because we had a crawler code that when run used dir() to move around in folder structures, find files and process them while building the paths using this core script idea in a recursive manner:

a = dir();

if k<=2; error('folder is empty'); end;

for k = 3:length(a)
   path = [a(k).folder '\' a(k).name];
   process_file(path);
end

however, when trying to use that path and '\\server\share' is there instead of 'Z:\', the code does not work. Of course as workaround the '\\server\share' can be replaced automatically. Another option is to reference everything relative to the current folder, but the issue remains. Creating an absolute address that a command such as load() or csvread() can use is not possible using the output of dir and constructing a path with it ("path = [a(k).folder '\' a(k).name]").

Thank you for your time and considering this issue

comment #4:

> Does it really just return the server? And not the share?
>
> IIUC, Windows is returning `\\server\share\file` for files on network shares for `FindFirstFileW` and `FindNextFileW`. `__wglob__` (the underlying work horse for the `dir` function on Windows) is using these functions to be able to handle non-ASCII characters in paths. That'll probably stay that way.
>
> Is that causing problems for you?
>

Does it really just return the server? And not the share?

IIUC, Windows is returning `\\server\share\file` for files on network shares for `FindFirstFileW` and `FindNextFileW`. `__wglob__` (the underlying work horse for the `dir` function on Windows) is using these functions to be able to handle non-ASCII characters in paths. That'll probably stay that way.

Is that causing problems for you?

Forgot to mention: You can test if this is working for you now with a nightly build from here:
https://buildbot.octave.space/#/download

Hello,

I am reporting a bug, as I noticed the behavior of dir() changed from 6.4.0 to 7.1.0. Lets say we have a network drive called '\\The_network_drive\' mounted in 'Z:\'. And there is one folder in it, called 'The_folder' (Z:\The_folder), which has one file 'The_file.txt'.

In 6.4.0, if we are standing in 'Z:\' and we write:

+Verbatim+

>> a = dir();
>> b = dir([a(3).folder '\' a(3).name]);

b =

 3x1 struct array containing the fields:

    name
    folder
    date
    bytes
    isdir
    datenum
    statinfo

-Verbatim-

we will get the contents of 'The_folder' in b, in a structure ('.', '..','The_file.txt')

However, in 7.1.0, if we do the same, it does not work. Because in 7.1.0, a(3).folder is not 'Z:\', but '\\the_network_drive\', and when doing b = dir('\\the_network_drive\The folder'), dir returns an empty structure.

+Verbatim+

>> a = dir();
>> b = dir([a(3).folder '\' a(3).name]);

b =

 0x1 struct array containing the fields:

    name
    folder
    date
    bytes
    isdir
    datenum
    statinfo

+Verbatim+

Following this logic, any recursive element or "folder crawler" we want to write based on dir() that works with network drives will have the issue of not being able to reference its absolute address correctly, or more specific, in a useful way.

Thank you for reading and considering the issue.

Running on Windows 10 21H2, with installer versions (x64) of both octave 6.4.0 and 7.1.0