[Octave-bug-tracker] [bug #62847] addpath fails to process network pathnames

[Philip Nienhuis]

Follow-up Comment #7, bug #62847 (project octave):

Thanks for the suggestions Markus, I was already busy trying most of them
out.

Below obfuscated paths are shown for my company's IT security, sorry for that.
I tried with the real ones, of course.
And all in the GUI (I rarely if ever use the CLI).


cd ('Q:\full\path\to\network\subdir')
works fine. As do 'dir' and 'ls'.
In the browser pane and main menu 'Current Directory' box I see a drive letter
and full path.

## From the network subdir where opt_lvm.m lives:
 >> which opt_lvm  (## lives in a network subdir)
'opt_lvm' is a function from the file
\\<server>.company.local\full\path\to\opt_lvm.m 
==> works

 >> canonicalize_file_name ('opt_lvm.m')
ans = \\<server>.company.local\full\path\to\pt_lvm.m
==> works

## From a different, "local" drive (FYI it's all on virtualized desktops) &
## after restarting Octave, just to be sure
 >> canonicalize_file_name ('Q:\full\path\to\opt_lvm.m')
ans = Q:\full\path\to\opt_lvm.m
==> hey this works as well ... same for just the subdir.

canonicalize_file_name and make_absolute_filename yield the same results.

These results makes me wonder where the expanded UNC paths come from under
what circumstances. Doesn't seem consistent across various local vs. network
locations.

In the GUI I cannot enter the path into the file browser pane nor in the
"Current subdirectory" box in the main menu. That is, I can paste it but
hitting <Enter> does nothing.
However, when using the drop-down menus there for previous subdirs, when I
click on the relevant network subdir it *does* work and gets me to that
location.
(Those entries came into that list thru the workaround I described in comment
#2, temporarily disabled for the tests above.)

BTW the actual full path has various intermediate directories with spaces in
the name.

Would you have any other suggestions?
Today I have a busy work day, maybe tonight or tomorrow night I could do more
tests and/or peruse the log at savannah to search for a possible candidate
cset that broke the "proper" behavior (or would you know a candidate cset?).
If found I can back it out (hopefully) and try a build with that tree.



    _______________________________________________________

Reply to this item at:

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

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