bugGNU Octave - Bugs: bug #62865, 'path' should return drive letter,...

 
 

bug #62865: 'path' should return drive letter, not UNC path when 'addpath' was called with drive letter

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 05 Aug 2022 06:50:39 PM UTC
 
Category:  Octave Function Severity:  2 - Minor
Priority:  3 - Low Item Group:  Matlab Compatibility
Status:  None Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Tue 09 Aug 2022 07:18:57 PM UTC, comment #5: 

not sure when that would happen.  on my server situation, if I move an m file to the root of a network drive, open octave cli, cd there, run the following I get:

>> which logistic_regression
'logistic_regression' is a function from the file \\full.server.name\path\to\mapped\serer\logistic_regression.m

>> help logistic_regression
'logistic_regression' is a function from the file \\alcnxfs.nae.ds.army.mil\ALC-HomeShare\nicholas.jankowski\logistic_regression.m

 -- [THETA, BETA, DEV, DL, D2L, P] = logistic_regression (Y, X, PRINT,
          THETA, BETA)
     Perform ordinal logistic regression.
...

I think whatever it is has to call system() for it to hit the CMD issue with UNC paths. First time i ran into the UNC issue I was using an old script calling an external tool with system.

does pkg do system calls? if so that might be the most common opportunity for this issue. maybe instrument control? but i don't think that really runs fully on windows (haven't checked in a while).

Nicholas Jankowski <nrjank>
Project Member
Tue 09 Aug 2022 06:37:16 PM UTC, comment #4: 

What about this?

debug> help ismember

'\\<server>.cmpany.local\FULL$\path\to\some\subdir'

CMD.EXE was started with the above path as the current directory.

UNC paths are not supported.  Defaulting to Windows directory.

'ismember' is a function from the file C:\Programs\Octave\Octave-8.0.0_20220807H\mingw64\share\octave\8.0.0\m\set\ismember.m

No idea if this can be harmful (not in this example, I got the help text). But it makes me wonder what happens if one wants to invoke some function living in a network drive in the path where the CMD processor is invoked behind the scenes - unsure is that is a real-life viable scenario.

Whether the UNC path is the Real Thing or not, on Windows equivalent drive letter paths seem to be more reliable in some cases.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 07 Aug 2022 08:39:32 AM UTC, comment #3: 

See also jwe's comment in bug #62847:
https://savannah.gnu.org/bugs/index.php?62847#comment43

> My point wasn't specifically about Unix-style symbolic links, but that if there can be more than one name for a directory (symbolic link, second mount point, whatever) it made sense to me to only store the One True Directory Name as an index for load path searching.  Maybe we should also store the name initially used (the one passed to addpath or other functions) and use that as the one to display to the user?

Markus Mützel <mmuetzel>
Project Member
Sat 06 Aug 2022 01:47:59 PM UTC, comment #2: 

possibly unrelated - thinking about reasoning for using canonicalize in addpath - does the canonicalize behavior turn windows/dos 8.3 filenames/paths into full-name paths? I recall there being a push a few versions ago to get away from parts of the code that resulted in 8.3 naming conventions, and wasn't sure if things like using canonicalize in addpath was part of fixing that

Nicholas Jankowski <nrjank>
Project Member
Sat 06 Aug 2022 07:22:58 AM UTC, comment #1: 

> Since (IIRC) 7.x.x, network paths returned by the 'path' command are shown as UNC paths, regardless of what kind of path was fed to the 'addpath' command.


To clarify: That is not correct in general. `canonicalize_file_name` still returns paths starting with the mapped network drive letter unless that path contains a symbolic link that points to a UNC network share that differs from the network share corresponding to the mapped network drive letter. Fwiw, it would also return that UNC path if the symbolic link pointing to a UNC network share would reside on a local disc.

Imho, that behavior of `canonicalize_file_name` is correct and matches how it is documented for POSIX.

If servers are swapped and mapped drive letters or symbolic links would be changed to point to different servers, `canonicalize_file_name` would automatically resolve to those new servers. So, I don't think the second point you raise is something we'd need to worry about.

Which sort of path (drive root or UNC) is easier to understand probably depends on which a user is more exposed to. E.g., where I'm working, UNC paths are used pretty commonly...

Imho in this particular case, we don't need to be 100% Matlab compatible. It's not like an evaluation result would differ because of this difference in behavior.

However, I tend to agree that it might be less surprising if addpath wouldn't change paths that it was fed. However, there is probably a reason why the paths are canonicalized currently. Changing anything revolving around the load path implementation tended to be critical in the past. So, if there is just a "cosmetic" reason for changing this, the "costs" of changing this need to be considered.
Additionally, this only affects very specific use cases (symbolic links that point to different network shares).

Lowering the priority because of this.

Markus Mützel <mmuetzel>
Project Member
Fri 05 Aug 2022 06:50:39 PM UTC, original submission:  

(split off from bug #62847)

Since (IIRC) 7.x.x, network paths returned by the 'path' command are shown as UNC paths, regardless of what kind of path was fed to the 'addpath' command. That is caused by 'addpath's helper function 'canonicalize_file_name', which cf. posix semantics should always return a UNC path.

OTOH Matlab at my work (we're still on r2014a due to the old graphics stuff, and occasionally use r2018b) returns drive letter search paths for network drives.

This is a call for restoring the old behavior of Octave and make it more Matlab-compatible, for the following reasons:

  • Drive letters are much more parsimonious, they're easier to understand than UNC paths, esp. for the Matlab newbies
  • Drive letters are more permanent than UNC paths. Servers can be swapped, file trees transferred, but drive letters usually persist
  • Matlab's path command returns drive letter paths if we feed it drive letter paths tru 'addpath'
  • (A variant of the previous) it is addpath that adds paths to the path, canonicalize_file_name is just a helper routine. I'd like the result of addpath to resemble as much as possible what I have fed it. For me that makes it a lot easier to e.g., figure out which variant of our Matlab script libraries is actually invoked.

I'd guess (just a hunch) that if canonicalize_file_name, called from addpath, successfully finds a network drive when given a drive letter path, addpath can conclude that the drive letter path was valid and can enter that to the search path rather than the UNC path.
Of course what happens next is quite relevant. If the interpreter must re-morph drive letter paths into UNC paths when searching each separate function, quite a bit of overhead is introduced. As Markus mentioned over in bug #62487, comment #35:

> (A first step would be to check why we are canonicalizing paths in the load path currently. Maybe that is not necessary?)

Again, Matlab doesn't seem to have any issues with it.

I've entered 'Matlab Compatibility' for 'Item Group" but it can be perceived as feature request just as well.

Philip Nienhuis <philipnienhuis>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-08-06 mmuetzel Priority5 - Normal 3 - Low

    Back to the top


    Powered by Savane 3.9