[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carlos Fuentes
Subject: [Octave-bug-tracker] [bug #62576] dir() behavior changed in octave 7.1.0 for network drives
Date: Mon, 20 Jun 2022 09:35:58 -0400 (EDT)

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];

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:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]