bugGNU Octave - Bugs: bug #59039, test failure with pathdef.m on...


bug #59039: test failure with pathdef.m on Windows 10

Submitted by:  Hartmut <hardy>
Submitted on:  Sat 29 Aug 2020 04:27:42 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  6.0.90 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 13 Sep 2020 05:10:17 PM UTC, comment #7: 

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Sun 13 Sep 2020 10:47:36 AM UTC, comment #6: 

I have now tested the patched file (patch from comment #5) pathdef.m on the Win10 PC from comment #0. Now all tests in pathdef.m pass.

Thanks for the patch, Rik. I think this issue can now be closed as FIXED.

Hartmut <hardy>
Tue 01 Sep 2020 03:07:44 PM UTC, comment #5: 

It was a little more involved than I thought, but I checked in cset 28668:e7248c5f6e1d on the stable branch that should fix this.

Rik <rik5>
Project Administrator
Tue 01 Sep 2020 02:56:23 PM UTC, comment #4: 

Very likely the short form of the name is the problem.  A simple one-line fix might be to use canonicalize_file_name.  The BIST test would change to

tmp_dir = canonicalize_file_name (tempname ());

I will make that change as a guess at the fix and you can verify when you return (presumably from holiday?).

Rik <rik5>
Project Administrator
Tue 01 Sep 2020 09:07:15 AM UTC, comment #3: 

I tried the debugging suggested in comment #2:

  • the temp dir is properly created in the windows file system - > OK
  • all seperation characters in the strings are always a backslash, no slashes anywhere -> OK

But: There may be trouble with the 8-character short form of windows file and folder names. I saw that tmp_dir is something like "C:\Users\CHARLO~1\xxxx", but p1 (after adding tmp_dir to it) begins like this: ".;C:\Users\Charlotte\xxxx". Can this be the root of troubles?

(I am sorry, but I will be offline for the next couple of weeks. I can only do further tests on this Win10 machine afterwards.)

Hartmut <hardy>
Tue 01 Sep 2020 12:11:18 AM UTC, comment #2: 

To debug this, could you modify pathdef.m and put a line


at the top of this BIST test and then run

test pathdef

You will get thrown to the Octave prompt and then you can use "dbnext" to step through the code.  I notice that we don't check the return code for "mkdir".  It is possible that there is a permissions issue that prevents you making a directory in the system-wide TMP folder and that once this command fails the rest of the test is destined to fail.

Another possibility is that the directory separation character is different between tempname() and addpath.  For example,

addpath ('c:/tmp')

may get turned in to the canonical 'c:\tmp' in the listing from path() and so strfind fails.

Rik <rik5>
Project Administrator
Sat 29 Aug 2020 07:16:14 PM UTC, comment #1: 

I have NOT seen this test failure on a second (totally different) Win10 machine I also tested.

Hartmut <hardy>
Sat 29 Aug 2020 04:27:42 PM UTC, original submission:  

I have installed the current release candidate (octave-6.0.90a-w64-installer.exe) on a Win 10 machine. I started Octave with the shortcut icon on the desktop. Running the test suite gives me one "regression" and one "test failure". This bug report is about the test failure of pathdef.m:

Here is the output of a later test run on pathdef.m:

>> test pathdef
***** test
path_orig = path ();
tmp_dir = tempname ();
   mkdir (tmp_dir);
   addpath (tmp_dir);
   p1 = path ();
   p2 = pathdef ();
   assert (! isempty (strfind (p1, tmp_dir)))
   assert (isempty (strfind (p2, tmp_dir)))
   rmdir (tmp_dir);
   path (path_orig);
!!!!! test failed
assert (!isempty (strfind (p1, tmp_dir))) failed

Hartmut <hardy>


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

Attach Files:

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 rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-13 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2020-09-01 rik5 Item GroupNone => Other
        StatusNeed Info => Ready For Test
    2020-09-01 rik5 StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5