[Octave-bug-tracker] [bug #62576] dir() behavior changed in octave 7.1.0 for network drives

[Carlos Fuentes]

Follow-up Comment #6, bug #62576 (project octave):

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


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62576>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/