bugGNU Octave - Bugs: bug #34731, Octave cannot run m-files from a...


bug #34731: Octave cannot run m-files from a removable drive with a subst disk

Submitter:  jb <jb2ndr>
Submitted:  Thu 03 Nov 2011 02:29:55 AM UTC
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Jackie Open/Closed:  * Closed
Release:  * 3.2.4 Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Mon 20 Jan 2014 03:02:12 AM UTC, comment #10: 

Reading through this bug report history, this bug does indeed look identical to bug #31080. User m-files are not found in a root directory of a Windows filesystem because the root directory does not have a modification timestamp associated with it. There is probably a similar bug with network shares.

Closing as duplicate, please post further comments to bug #31080.

Mike Miller <mtmiller>
Project Administrator
Fri 10 Feb 2012 03:25:09 PM UTC, comment #9: 


my previous comment contained an inaccuracy:

I DO have a debug version of octave-3.4.2 lying around, and it shows the error.

How can I proceed? (how to set a breakpoint where; what variables to inspect; etc).

Philip Nienhuis <philipnienhuis>
Project Member
Fri 03 Feb 2012 07:54:12 PM UTC, comment #8: 

Here you go:

octave:6> isdir ('F:')
ans =  1
octave:7> isdir ('F:\')
ans =  1
octave:8> isdir ("F:\")
error: unterminated string constant
parse error:

  syntax error

>>> isdir ("F:\")


octave:8> isdir ("F:\\")
ans =  1
octave:9> isdir ("F:/")
ans =  1
octave:10> isdir ("F:/svn/octave.sf.net")
ans =  1

Unfortunately I have no debug Octave. Tatsuro might have.
The backslash is a problematic character on Windows, as far as Octave goes.

But even while using Octave on Windows, I often use forward slash rather than backslash in path names - it works as good as a backslash (!), as you can see above in prompts 9 & 10.
In my .octaverc file I have forward slashes in all path names (to default dir, to Notepad++ editor, etc).

Perhaps this is a way out? to simply skip "filesep" - I can only guess that the MinGW file I/O libs substitute the proper file separator at the right time.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 03 Feb 2012 07:17:49 PM UTC, comment #7: 

I think you have discovered something.  I tried something similar using the root directory on a Unix box, but everything worked.  On UNIX the file separator is '/'.  I think the file separator being '\' on Windows, and the fact that this is often a reserved escape character, is probably causing problems.

What does "isdir ('F:\')" return?  The single quotes are necessary to prevent the '\' character as being treated as special.

I don't think this problem would be very hard to resolve if you were to just step through the code being executed.  Do you have access to a version compiled with support for gdb?  If you can compile from source I can help set up the flags for debug compilation correctly and in running gdb.

Rik <rik5>
Project Administrator
Fri 03 Feb 2012 05:45:20 PM UTC, comment #6: 

octave:3> edit scrpt.m
...editing script.m
octave:4> scrpt
error: `scrpt' undefined near line 4 column 1
octave:4> ls
 Volume in drive F is BIGWIN1
 Volume Serial Number is 746C-E43B

 Directory of f:\

[AthlonXP_WinXP]  [tmp]             [GPS_Maps]        NZ_Uitgaven.xls   [Mail_BU]
[Home]            scrpt.m           [Waternet&WLB]    BigWin1
[svn]             X3SPOEM_EN.iso    [Literatuur]      [Garmin]
BIRDS20.ISO       [Projecten]       [MSPIe]           [dfsee]
               5 File(s)  1 233 603 926 bytes
              12 Dir(s)   1 586 806 784 bytes free
octave:5> file_in_loadpath ("scrpt.m")
ans =

As you can see, ls sees scrpt.m, but file_in_loadpath doesn't.

Could it be related to the trailing backslash in "F:\" ?

Philip Nienhuis <philipnienhuis>
Project Member
Fri 03 Feb 2012 05:23:02 PM UTC, comment #5: 

I don't have a Windows machine so helping with the debug is difficult.  I'd like to understand more about how Octave is not seeing the directory.

After you add a new m-file, say "NEW_FILE.m", to a root directory while still in Octave, what is the result of

file_in_loadpath ("NEW_FILE.m")

I'm trying to understand whether Octave doesn't really see the file, or if the caching mechanism for m-files is somehow filtering it out.

Rik <rik5>
Project Administrator
Fri 03 Feb 2012 03:43:40 PM UTC, comment #4: 

AFAICS this is a duplicate of bug #31080 and -indeed- #33389 (although the latter bug report contains too little informative to find out what is going on).

The issue is that Octave doesn't seem to pick up all changes in "." (current directory) until a restart, if that directory is the root of the drive.

On my home network, Octave 3.6.0 MinGW does pick up and run m-files on network shares, be it in the root or in subdirs.

Once Octave is up and running, and an m-file is added in the root of any drive (network share, thumb drive, local drive), Octave will see it (through "dir" or "ls") but isn't able to run it.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 03 Nov 2011 07:31:06 PM UTC, comment #3: 

It would be useful if someone could test whether this bug has been resolved.  I don't know if you are using Cygwin or MinGW.  Instructions for both are at http://wiki.octave.org/wiki.pl?OctaveForWindows.  You will need to scroll down to discover a 3.4.3 MinGW version or a 3.4.2 Cygwin version.

Rik <rik5>
Project Administrator
Thu 03 Nov 2011 06:15:43 PM UTC, comment #2: 

After reviewing of the referenced bug I have determined that it is in fact the network share not the fact that it was a removable drive mapped to a virtual disk drive letter via the subst command.
I am running Windows XP and the current windows distribution is 3.2.4. I am guessing that I would need to download the current version and compile it? I will actually be happy to help do this if you are unsure that the bug has been fixed and you need it tested. Otherwise my immediate needs are met. If I knew how to update the windows distribution I would also do that.

jb <jb2ndr>
Thu 03 Nov 2011 04:58:30 AM UTC, comment #1: 

This appears to be related to bug #33389.  The 3.2.4 release is deprecated and no longer supported.  Can the reporter try upgrading to the 3.4.X series?

Rik <rik5>
Project Administrator
Thu 03 Nov 2011 02:29:55 AM UTC, original submission:  

When attempting to run an m-file script from a removable drive with a link to a virtual drive octave responds:
octave-3.2.4.exe:5> rf
error: `rf' undefined near line 5 column 1

octave-3.2.4.exe:5> dir
.                        cvsproj.configurations   elecproj.current
..                       cvsproj.current          mathproj.current
RECYCLER                 elecproj.configurations  rf.m
If the directory tree is copied to a local drive and the octave directory changed to the directory containing the file rf.m again the file will be found and parsed.

jb <jb2ndr>


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

Attach Files:

No files currently attached


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jb2ndr (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.





    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-20 mtmiller Open/ClosedOpen Closed
        Dependencies- Depends on bugs #31080
    2012-02-03 philipnienhuis StatusNone Duplicate
    2011-11-03 rik5 Dependencies- Depends on bugs #33389

    Back to the top

    Powered by Savane 3.9