bugGNU Octave - Bugs: bug #31080, User scripts or functions created...

 
 

bug #31080: User scripts or functions created during a session on Windows are not found

Submitter:  J-D Bonjour <jdb>
Submitted:  Sun 19 Sep 2010 10:42:38 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Release: 
Operating System:  * Microsoft Windows Fixed Release:  9.4.0
Planned Release:  9.4.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 01 Feb 2025 10:46:24 PM UTC, comment #88: 

@mmuetzel: This bug seems to be fixed for 10.1.  I changed the Planned Released and Fixed Release fields to 9.4 since this bug is essentially the entire reason to have a 9.4 release.  I'm closing it, but it can be re-opened (please God no!) if it truly re-appears in 9.4.

Rik <rik5>
Group administrator
Thu 23 Jan 2025 06:54:04 PM UTC, comment #87: 

comment #84:

> @dennisc_hi: If you were able to consistently reproduce this error (independent on some time intervals), you were very likely seeing a different issue.


I am able to consistently reproduce this error using Octave 9.3.0 on my Windows 11 PC. It does not work sometimes and fail other times.

I can't seem to get my Octave 10.0.0 (local MINGW64/MSYS2 build of mercurial source) to fail, ever.

The version info for my Octave 9.3 is:

>> ver
----------------------------------------------------------------------
GNU Octave Version: 9.3.0 (hg id: 5854a65df8f5)
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-6.2 Windows 6.2  x86_64


The version info for my Octave 10.0 is:

>> ver
----------------------------------------------------------------------
GNU Octave Version: 10.0.0 (hg id: 00671f5dbc55+)
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-10.0 Windows 10.0  x86_64


They are built with different source files and it appears they are compiled for different versions of the Windows OS.

I also noticed that my Octave 9.3 is executing several commands in my C:\Users\DennisC\.octaverc file. One of these adds a second, explicit, path to current directory, C:\Users\DennisC, in addition to ".".

EDITOR("notepad++.exe")
addpath("~")
addpath("~/Downloads")
pkg load control
pkg load signal


Interestingly, to verifying that the .octaverc file was adding the explicit path to C:\Users\DennisC to the load path I renamed the .octaverc file to hide.octaverc and restarted Octave 9.3.0. I verified the explicit path was not listed on the load path. I then created a new script file and immediately executed it without error. I repeated the test for a second function file and it also worked correctly. After typing this, thinking the issue might be related to the alternate load path, I repeated my test a third time and it failed as before. I waited a while longer and created a fourth file and it worked. I could also execute the third file at that point as well. So it appears that my Octave 9.3.0 is inconsistent after all, contrary to my earlier claim. I guess I was just unlucky in many previous tests.

I executed your test sequence with my Octave 10.0.0, creating a more than a dozen new files and immediately executing them. I don't type too fast, so this process took about 10-15 minutes. Every one of the files executed correctly. I repeated once more after typing this and it also worked.

It seems to be fixed in Octave 10.0 with your patch.

Dennis Cote <dennisc_hi>
Wed 22 Jan 2025 04:59:40 PM UTC, comment #86: 

If I understand correctly, the interpreter has to stop running and then start again. That is not possible from inside a script or function afaict. Only a user can do that by manually running commands.

Markus Mützel <mmuetzel>
Group administrator
Wed 22 Jan 2025 04:55:19 PM UTC, comment #85: 

hmmm. okay. I was wondering if a system('touch filename.dat') or platform equivalent would behave the same as a 'manual' file creation.

Nicholas Jankowski <nrjank>
Group Member
Wed 22 Jan 2025 04:51:33 PM UTC, comment #84: 

@dennisc_hi: If you were able to consistently reproduce this error (independent on some time intervals), you were very likely seeing a different issue. The one that was fixed with the last changes here required that some file times were taken at specific points in some time intervals. The process that I described was meant to make sure that these time intervals are sampled such that the issue is triggered pretty reliably (Nick summarized that correctly).

Testing means that we need to try and make sure that the time stamps are actually correct now (and there isn't another thinko in the updated implementation).

@Nick: It is probably not possible to implement a BIST for the issue that is addressed by the latest change. If I understand correctly, it requires manually creating files in a folder in the load path. Creating these files automatically in a script would probably pass through different code paths.

(Btw: It turns out this wasn't caused by the same issue for which this report was opened in 2010. If I understand correctly, it's a regression from bug #59711 - around May 2023.)

Markus Mützel <mmuetzel>
Group administrator
Wed 22 Jan 2025 04:08:08 PM UTC, comment #83: 

First, congratulations to all on possibly finally tracking down this rather frustrating problem (Sep 2010, assuming there isn't something older that was closed before!). no embarrassment expected, as described it was a difficult one to troubleshoot.

I suspect to verify the bug and fix mmuetzel is suggesting a test that can recreate a situation related to that ~7minute time interval defined by the magnitude of the bit shift that was corrected. This test should be able to be run with guaranteed failure on unpatched code and then pass with current code.

I'm not sure how to create a BIST for something like that though. It would be nice to have a built-in test for something like this.  Can a BIST mess with the system time variable to create a condition guaranteeing a failure?

Nicholas Jankowski <nrjank>
Group Member
Wed 22 Jan 2025 03:34:18 PM UTC, comment #82: 

comment #81:

> I'm not sure I understood your test procedure correctly.


I consistently see the problem using Octave 9.3.0. It happens when a new file is saved to the current directory, which is on the load path, and is not a special directory like the root of a drive, as demonstrated in comment #78. That also shows the path(path()) workaround does work to allow the new file to be executed.

I retested using my Octave 10.0.0 with hgid 00671f5dbc55+, which includes your bit shift direction corrections. I did not see the problem using the same current directory I had used with Octave 9.3.0. as demonstrated in comment #79.

There were previous reports that the issue depended upon the location of the current directory. Some said it failed when the current directory was the root of a drive. Some said it failed on alternate drives. Some have suggested it fails on MS OneDrive or other network drives. I retested my Octave 10.0.0 with the current directory set to each of those type of locations without any errors reported. 

Many of the older tests used the stat function to show the mod time of the current directory. I saw nothing in this bug report history that said the mod time was no longer used, so I added the info when testing. Thanks for the tip about 'format long'.

> Assuming that the issue was actually caused by the erroneous bit shift (which is our best assumption currently imho), the following test procedure would probably suffice:


If I understand you correctly, you are suggesting testing for some other cause of the issue since the timestamp error has been corrected.

> Try to manually create new files in the same folder repeatedly for an extended period of time (e.g., one new .m file every - let's say - approximately 20 seconds for a period of 8 to 10 minutes or until the issue occurs) and try to execute it manually immediately after creating the new file. That folder can probably be the current directory or any other folder in the load path. Each of the new files needs to be named differently from any files that already exist in that folder at that point.
> It might also be necessary to not hit enter on an empty prompt (nor execute any other command) between creating the new file and trying to execute it.


Can you explain what this is testing for? Given that the timestamps are now correct, what is your theory of failure that you are trying to test?

Dennis Cote <dennisc_hi>
Tue 21 Jan 2025 08:07:31 AM UTC, comment #81: 

This report is quite old. In the meantime, the implementation of the load path has changed, and it no longer uses the date/time from stat on Windows. So, the value of the time stamps returned by the `stat` function doesn't matter for this issue. (Btw: you can change the format in which double precision floating point numbers are printed by default by running, e.g., `format long` before inspecting the respective numbers.)

I'm not sure I understood your test procedure correctly. So, I don't know whether it was sufficient to test if this bug is fixed.

Assuming that the issue was actually caused by the erroneous bit shift (which is our best assumption currently imho), the following test procedure would probably suffice:
Try to manually create new files in the same folder repeatedly for an extended period of time (e.g., one new .m file every - let's say - approximately 20 seconds for a period of 8 to 10 minutes or until the issue occurs) and try to execute it manually immediately after creating the new file. That folder can probably be the current directory or any other folder in the load path. Each of the new files needs to be named differently from any files that already exist in that folder at that point.
It might also be necessary to not hit enter on an empty prompt (nor execute any other command) between creating the new file and trying to execute it.

Markus Mützel <mmuetzel>
Group administrator
Mon 20 Jan 2025 08:35:46 PM UTC, comment #80: 

I again repeated my testing with the new function file on the root of another NTFS drive using my Octave 10.0.0. A new file bug4.m was created in the root of my D: drive and this file was executed successfully immediately after creation.

I also repeated my testing creating a new file bug5.m in my Documents folder on my OneDrive. That file was also executed correctly after creation.

I would say this bug seems to be fixed using the current Octave 10.0.0 source.

I'm somewhat concerned that the current format of the stat output is less useful than it used to be, but that should be another bug report.

Dennis Cote <dennisc_hi>
Mon 20 Jan 2025 08:19:03 PM UTC, comment #79: 

I repeated my previous tests using my local build of Octave 10.0.0. The undefined error did not occur in a the same subdirectory.


GNU Octave, version 10.0.0
Copyright (C) 1993-2024 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

Home page:            https://octave.org
Support resources:    https://octave.org/support
Improve Octave:       https://octave.org/get-involved

For changes from previous versions, type 'news'.

>> pwd
ans = C:\Users\DennisC
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 2
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 2
    size = 0
    atime = 1.7374e+09
    mtime = 1.7374e+09
    ctime = 1.7268e+09
    blksize = NaN
    blocks = NaN

>> dir bug2.m
warning: dir: nonexistent directory 'bug2.m'
warning: called from
    dir at line 192 column 5

>> edit bug2.m
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 2
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 2
    size = 0
    atime = 1.7374e+09
    mtime = 1.7374e+09
    ctime = 1.7268e+09
    blksize = NaN
    blocks = NaN

>> dir bug2.m
bug2.m
>> bug2
bug testing v10
ans = 0
>> ver
----------------------------------------------------------------------
GNU Octave Version: 10.0.0 (hg id: 00671f5dbc55+)
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-10.0 Windows 10.0  x86_64
----------------------------------------------------------------------
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control  |   4.1.0 | C:\Users\DennisC\AppData\Roaming\octave\api-v59\packages\control-4.1.0
      signal  |   1.4.6 | C:\Users\DennisC\AppData\Roaming\octave\api-v59\packages\signal-1.4.6
>>


I found the warnings from the first dir command a little disturbing, since I was looking for a file not a directory, but I see the argument is described as a directory in the documentation.


Dennis Cote <dennisc_hi>
Mon 20 Jan 2025 07:56:58 PM UTC, comment #78: 

Rereading these bug reports start from the beginning I see there is another issue with directory timestamp on Windows directories. I decided to retest using my current directory. I still see this issue. A slightly edited command history (some file names redacted) is shown below. I'm using Octave 9.3.0 on Windows 11.


GNU Octave, version 9.3.0
Copyright (C) 1993-2024 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

Home page:            https://octave.org
Support resources:    https://octave.org/support
Improve Octave:       https://octave.org/get-involved

For changes from previous versions, type 'news'.

>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 2
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 2
    size = 32768
    atime = 1.7374e+09
    mtime = 1.7371e+09
    ctime = 1.7268e+09
    blksize = NaN
    blocks = NaN

>> pwd
ans = C:\Users\DennisC
>> dir

...
I redacted many file names.
File bug.m did not exist.

>> edit bug.m
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 2
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 2
    size = 32768
    atime = 1.7374e+09
    mtime = 1.7374e+09
    ctime = 1.7268e+09
    blksize = NaN
    blocks = NaN

>> dir

...
I redacted many file names.
File bug.m does exist in current directory
which is on the load path.

>> dir bug.m
bug.m
>> bug
error: 'bug' undefined near line 1, column 1
>> path(path());
>> bug
bug testing
ans = 0
>>


The content of bug.m is a large comment header inserted by the edit command followed by:


function retval = bug (input1, input2)
  display("bug testing");
  retval = 0;
endfunction


The first thing I noticed is that the format of the timestamps returned by the stat command have changed from integers to exponential floating point with only 5 digits of precision.

My C: drive is an NTFS drive. This is happening in a sub-directory rather than at the root of a drive.

The path(path()) workaround does cause Octave to find and execute the bug.m file.

Dennis Cote <dennisc_hi>
Sat 18 Jan 2025 01:15:19 PM UTC, comment #77: 

@dennisc_hl: It is expected that the interpreter can not find .m file functions that are saved at a location that is not in the load path.
This report is not about that. And imho, we shouldn't side-track this report with a potential feature request.
If you really believe that new directories should be added to the load path (just) because the editor is used to save to a location that doesn't happen to be in the load path yet, please open a separate feature request.

Testing whether new files in the load path are found more reliably now would still be appreciated.

Markus Mützel <mmuetzel>
Group administrator
Fri 17 Jan 2025 07:25:10 PM UTC, comment #76: 

I tried to run the command using the green play button in the Editor and I was greeted by a very explanatory dialog attached as Change_or_Add.png

I suspect many users are switching from the Editor to the Command Window and trying to type the name of the new command expecting that the path to the new file was added to the load path when it was saved, like I was.

In the Editor, it seems I have to explicitly click the Add Directory to Load Path button to be able to execute the file.


Dennis Cote <dennisc_hi>
Fri 17 Jan 2025 06:58:43 PM UTC, comment #75: 

I continued testing with Octave 9.3.0 installed by the Windows release installer at https://octave.org/download.

If I create a new *.m file and save it to a path that is not already in the Octave path() list then its path is not added to the octave path list and trying to execute the file in the command window produces the undefined error.

I dumped the path() list before creating the new file and again after saving the file. The file's path (using the Editor by right-clicking the file's tab heading and selecting Copy Full File Path) is C:/Users/DennisC/Octave_Files/testing/test_add_vec_3.m. The path list after saving the file is:

>> ps = transpose(strsplit(path(), ";"))

ps =
{
  [1,1] = .
  [2,1] = C:\Users\DennisC\AppData\Roaming\octave\api-v59\packages\signal-1.4.6\x86_64-w64-mingw32-api-v59
  [3,1] = C:\Users\DennisC\AppData\Roaming\octave\api-v59\packages\signal-1.4.6
  [4,1] = C:\Users\DennisC\AppData\Roaming\octave\api-v59\packages\control-4.1.0\x86_64-w64-mingw32-api-v59
  [5,1] = C:\Users\DennisC\AppData\Roaming\octave\api-v59\packages\control-4.1.0
  [6,1] = C:\Users\DennisC\Downloads
  [7,1] = C:\Users\DennisC
  [8,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\lib\octave\9.3.0\site\oct\x86_64-w64-mingw32
  [9,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\lib\octave\site\oct\api-v59\x86_64-w64-mingw32
  [10,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\lib\octave\site\oct\x86_64-w64-mingw32
  [11,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\site\m
  [12,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\site\api-v59\m
  [13,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\site\m
  [14,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\site\m\once_only
  [15,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\site\m\startup
  [16,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\lib\octave\9.3.0\oct\x86_64-w64-mingw32
  [17,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m
  [18,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\audio
  [19,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\deprecated
  [20,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\elfun
  [21,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\general
  [22,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\geometry
  [23,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\gui
  [24,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\help
  [25,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\image
  [26,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\io
  [27,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\java
  [28,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\legacy
  [29,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\linear-algebra
  [30,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\miscellaneous
  [31,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\ode
  [32,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\optimization
  [33,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\path
  [34,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\pkg
  [35,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\plot
  [36,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\plot\appearance
  [37,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\plot\draw
  [38,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\plot\util
  [39,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\polynomial
  [40,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\prefs
  [41,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\profiler
  [42,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\set
  [43,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\signal
  [44,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\sparse
  [45,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\specfun
  [46,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\special-matrix
  [47,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\startup
  [48,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\statistics
  [49,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\strings
  [50,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\testfun
  [51,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\time
  [52,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\m\web
  [53,1] = C:\Program Files\GNU Octave\Octave-9.3.0\mingw64\share\octave\9.3.0\data
}
 
Which does not contain the path to the newly created and saved file which is in C:/Users/DennisC/Octave_Files/testing/

Trying to execute the new script file produces the undefined error:

>> test_add_vec_3

error: 'test_add_vec_3' undefined near line 1, column 1

Dennis Cote <dennisc_hi>
Fri 17 Jan 2025 03:57:53 PM UTC, comment #74: 

I just tested using a local MINGW64 build of Octave 10.0.0 and I am still seeing the same error under Windows 11.

I am using the Octave GUI. I defined a simple function in a new file using the Editor tab.

function total = add_vec(vec)
  total = sum(vec);
endfunction

I then saved the function to a file with the name add_vec.m in the current directory (which is my Windows home directory C:/Users/DennisC).

I switch back to the command window tab and try to execute the new function.

>> v=[1, 2, 3, 4];
>> add_vec(v)

error: 'add_vec' undefined near line 1, column 1

>> version("-hgid")

ans = 00671f5dbc55+

I confirmed that my source has the changes to the shift operator. My liboctave/system/oct-time.cc file_time() methods are:


file_time::file_time ()
{
#if defined (OCTAVE_USE_WINDOWS_API)
  FILETIME curr_file_time;
  GetSystemTimeAsFileTime (&curr_file_time);
  m_time
    = (static_cast<OCTAVE_TIME_T> (curr_file_time.dwHighDateTime)) << 32
      | (static_cast<OCTAVE_TIME_T> (curr_file_time.dwLowDateTime));
#else
  time_t ot_unix_time;
  long ot_usec;
  octave_gettimeofday_wrapper (&ot_unix_time, &ot_usec);
  // Discard usec.  We are assuming a 1 second resolution anyway.
  m_time = ot_unix_time;
#endif
}

file_time::file_time (const std::string& filename)
{
#if defined (OCTAVE_USE_WINDOWS_API)
  std::wstring wfull_name = sys::u8_to_wstring (filename);
  WIN32_FILE_ATTRIBUTE_DATA file_attributes;

  if (! GetFileAttributesExW (wfull_name.c_str (), GetFileExInfoStandard,
                              &file_attributes))
    {
      m_time = 0;
      return;
    }

  FILETIME last_write_time = file_attributes.ftLastWriteTime;

  m_time
    = (static_cast<OCTAVE_TIME_T> (last_write_time.dwHighDateTime)) << 32
      | (static_cast<OCTAVE_TIME_T> (last_write_time.dwLowDateTime));
#else
  file_stat fs = file_stat (filename);
  m_time = fs.mtime ().unix_time ();
#endif
}


In the past this undefined error could be resolved by quitting and restarting Octave, but that does not work now. I quit Octave and restarted the GUI. I then reentered the commands above and got the same error. I then tried the path(path()) workaround and it also failed.

>> v = [1, 2, 3, 4];
>> add_vec(v)

error: 'add_vec' undefined near line 1, column 1

>> path(path())
>> add_vec(v)

error: 'add_vec' undefined near line 1, column 1

Then I checked the path the function file was saved to by hovering my mouse over the file's filename tab in the Editor. It was saved in my Windows home directory at C:/Users/DennisC/add_vec.m. Then I noticed that the Current Directory shown in the Octave toolbar is my MINGW64/MSYS2 home directory C:\tools\msys64\home\DennisC. I quit and restarted Octave to verify that this was the initial current directory. I repeated the test and again got the undefined error.

>> v = [1, 2, 3, 4];
>> add_vec(v)

error: 'add_vec' undefined near line 1, column 1

I then used the Current Directory combo box on the toolbar to change the Current Directory to my Windows home directory (where the file exists) and repeated the failed command. The function executed as expected.

>> add_vec(v)

ans = 10

I then dumped my path to see where Octave is looking for functions.

>> ps = transpose(strsplit(path(), ";"))

ps =
{
  [1,1] = .
  [2,1] = C:\tools\msys64\home\DennisC\usr\lib\octave\10.0.0\site\oct\x86_64-w64-mingw32
  [3,1] = C:\tools\msys64\home\DennisC\usr\lib\octave\site\oct\api-v59\x86_64-w64-mingw32
  [4,1] = C:\tools\msys64\home\DennisC\usr\lib\octave\site\oct\x86_64-w64-mingw32
  [5,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\site\m
  [6,1] = C:\tools\msys64\home\DennisC\usr\share\octave\site\api-v59\m
  [7,1] = C:\tools\msys64\home\DennisC\usr\share\octave\site\m
  [8,1] = C:\tools\msys64\home\DennisC\usr\share\octave\site\m\startup
  [9,1] = C:\tools\msys64\home\DennisC\usr\lib\octave\10.0.0\oct\x86_64-w64-mingw32
  [10,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m
  [11,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\audio
  [12,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\deprecated
  [13,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\elfun
  [14,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\general
  [15,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\geometry
  [16,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\gui
  [17,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\help
  [18,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\image
  [19,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\io
  [20,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\java
  [21,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\legacy
  [22,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\linear-algebra
  [23,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\miscellaneous
  [24,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\ode
  [25,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\optimization
  [26,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\path
  [27,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\pkg
  [28,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\plot
  [29,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\plot\appearance
  [30,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\plot\draw
  [31,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\plot\util
  [32,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\polynomial
  [33,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\prefs
  [34,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\profiler
  [35,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\set
  [36,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\signal
  [37,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\sparse
  [38,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\specfun
  [39,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\special-matrix
  [40,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\startup
  [41,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\statistics
  [42,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\strings
  [43,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\testfun
  [44,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\time
  [45,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\m\web
  [46,1] = C:\tools\msys64\home\DennisC\usr\share\octave\10.0.0\data

The only directory that is not one of Octave's internal directories is ".", the current directory. So it seems Octave is saving the new files to a directory that is not on the path and not adding that directory to the path.

I'm now trying to see if I can repeatably get it to save to some directory other than the current directory.

Dennis Cote <dennisc_hi>
Fri 17 Jan 2025 02:03:12 PM UTC, comment #73: 

I grafted that change to the stable branch:
https://github.com/gnu-octave/octave/commit/26776f991cdc96f1dcfb1895b9734dfd9f337e57 (link to the GitHub mirror, Mercurial on Savannah seems to be down currently)

Could you please check if this is still an issue with a nightly build from Jan-17 or later?
https://nightly.octave.org/#/download

Markus Mützel <mmuetzel>
Group administrator
Fri 10 Jan 2025 10:57:43 AM UTC, comment #72: 

Found a pretty embarrassing error in the calculation of file timestamps on Windows which is very likely the reason for the issues with missed updates of the load path in Octave 9 on Windows.
jwe helped to fix that during yesterday's office hour (thanks again for that). I pushed that fix to the repository here:
https://hg.savannah.gnu.org/hgweb/octave/rev/b11d73d38936

That error lead to a situation where essentially the high order bits of the file timestamps were ignored. Only the low order bits of the file timestamp were used for tracking modification times. These low order bits overflow about every 7 minutes.
So, it depended on when a file was saved relative to the start of any of these previous ~7 minute intervals and when the current ~7 minute interval started. That made this issue to appear so random. (In most of my attempts I made a modification to the source, rebuilt, and tried to create and run multiple files in a row. It looks like I didn't cross one of those ~7 minute interval borders just by "good" luck during any of these tests.)

I followed up by backing out the change from comment #67 because it is very likely not needed (and didn't help to work around that embarrassing error in the first place):
https://hg.savannah.gnu.org/hgweb/octave/rev/e78537c99513


Markus Mützel <mmuetzel>
Group administrator
Tue 07 Jan 2025 08:49:52 PM UTC, comment #71: 

From your error log:

> could not open C:toolsmsys64tmpPkzKdzDCTH: No such file or directory

Looks like some backslash file separators got eaten there. The file should probably be something like:
C:/tools/msys64/tmp/PkzKdzDCTH
So if I'm right it needs to be figured out where the backslash fileseps come from and then they need to be replaced with forward slashes.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 06 Jan 2025 07:44:49 PM UTC, comment #70: 


> The Octave for Windows binaries that can be downloaded from the GNU mirrors are cross-compiled on Linux.


That's what I thought.

The "Octave for Windows binaries that can be downloaded from the GNU mirrors" is what I meant by the "Windows release packages". That is the version of Octave that almost all Windows users will be running.

You are testing using a different version of Octave built in a different manner. That may be why you are seeing different results.

I understand why you are building locally (in fact I am trying to do the same thing) to test changes, I'm just pointing out this difference may change the behavior.

BTW, I have been able to build Octave locally with MINGW64/MSYS2 and run it using the run-octave script, but I can't install any packages unless I run the "make install" step (see bug report https://savannah.gnu.org/bugs/index.php?45227). Unfortunately, the "make install" command fails with the following messages:

```
  GEN      build-aux/subst-script-vals.sh
config.status: creating build-aux/subst-script-vals.sh-tmp
config.status: executing build-aux/subst-script-vals.sh commands
  GEN      libinterp/dldfcn/__delaunayn__.oct
  GEN      libinterp/dldfcn/__fltk_uigetfile__.oct
  GEN      libinterp/dldfcn/__glpk__.oct
  GEN      libinterp/dldfcn/__init_fltk__.oct
  GEN      libinterp/dldfcn/__init_gnuplot__.oct
  GEN      libinterp/dldfcn/__ode15__.oct
  GEN      libinterp/dldfcn/__voronoi__.oct
  GEN      libinterp/dldfcn/audiodevinfo.oct
  GEN      libinterp/dldfcn/audioread.oct
  GEN      libinterp/dldfcn/convhulln.oct
  GEN      libinterp/dldfcn/fftw.oct
  GEN      libinterp/dldfcn/gzip.oct
  GEN      src/octave-cli-10.0.0.exe
  GEN      src/octave-gui-10.0.0.exe
  GEN      doc/interpreter/doc-cache
could not open C:toolsmsys64tmpPkzKdzDCTH: No such file or directory
makeinfo produced no output! at ../doc/interpreter/mk-doc-cache.pl line 114.
make[2]: * [Makefile:32815: doc/interpreter/doc-cache] Error 255
make[2]: Leaving directory '/c/OctaveSrc/octave/.build'
make[1]: * [Makefile:28695: install-recursive] Error 1
make[1]: Leaving directory '/c/OctaveSrc/octave/.build'
make: * [Makefile:29002: install] Error 2
```

Perhaps you know what is failing here.

FYI, I have a working texlive installation under MINGW64/MSYS2. I experienced the issue @mmuetzel reported to MSYS2 devs at https://github.com/msys2/MSYS2-packages/issues/3014 during my first Octave build without the --disable-docs flag. I downloaded the test.texi file used in that report and I am able to process it correctly using the texi2dvi command from the shell with or without setting the TEX environment variable. The Octave build still fails so, I had to add the --disable-docs flag and rebuild.

I now have a build with no documentation that won't let me install any packages (at least the signal and control packages I need), and I can't get it to complete the "make install" successfully. Any suggestions will be appreciated.

Dennis Cote <dennisc_hi>
Mon 06 Jan 2025 07:06:24 PM UTC, comment #69: 


> Are you testing on Windows?


Yes, I'm testing on Windows.

> Are you using the same build process that is used to build the Windows release packages?


What do you mean by "Windows release packages"?
I'm building relatively close to how the packages that are distributed by MSYS2 are built (i.e., I'm building natively on Windows/MinGW using compilers and dependencies from MSYS2).
The Octave for Windows binaries that can be downloaded from the GNU mirrors are cross-compiled on Linux.

Markus Mützel <mmuetzel>
Group administrator
Mon 06 Jan 2025 06:04:17 PM UTC, comment #68: 


> I can't reproduce the issue reliably.


Are you testing on Windows? Are you using the same build process that is used to build the Windows release packages?


Dennis Cote <dennisc_hi>
Mon 06 Jan 2025 05:55:26 PM UTC, comment #67: 

I wasn't able to reproduce the issue with those changes any more. So, I went ahead and pushed them to the default branch:
https://hg.savannah.gnu.org/hgweb/octave/rev/a1ce3c6a3e5e

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Sun 29 Dec 2024 03:47:46 PM UTC, comment #66: 

Oops. Forgot to attach the patch again after reloading this page.
Here it is.

(file #56724)

Markus Mützel <mmuetzel>
Group administrator
Sun 29 Dec 2024 03:45:31 PM UTC, comment #65: 

I can't reproduce the issue reliably. But sometimes it occurs for me, too, with the following steps:

  • Re-arrange the widgets such that the built-in editor and the command window widget are visible at the same time. (I was never able to reproduce the issue when the command window widget wasn't visible when I saved the file. That might not mean much because I can't reproduce the issue reliably in any case...)
  • Create a new file in the built-in editor and save it (e.g., as "test5.m")
  • Click into the command window widget and run the new file (e.g., with typing "test5" and hitting the "return" key).


Sometimes that executes the file for me. Some other times, I see the "... undefined near line 1, column 1" error. (Maybe, with approximately a 1 out of 4 chance that I get the error.)

The attached patch rehashes Octave's load path every time immediately after a file was saved (not only for new files).
With it, I wasn't able to reproduce the issue with the above steps (so far).

Markus Mützel <mmuetzel>
Group administrator
Tue 17 Dec 2024 08:18:55 PM UTC, comment #64: 

understood, and agreed. this was a point of discussion at today's developer meeting and we have some ideas to try to improve things for the next major release.

Nicholas Jankowski <nrjank>
Group Member
Tue 17 Dec 2024 07:43:37 PM UTC, comment #63: 

comment #61:

> can you mention the Windows version you're using


I'm running Windows 11 Pro 23H2. Just installed Octave 9.3.0.

> and where the file location is located (I would assume the default of C:/Users/_username_/... since you said user home directory)


Yes, in C:/Users/DennisC/ in my case.

This bug is very annoying, and I suspect it is a deal breaker for many new users who will run into this on Windows and then give up without searching for a work around. It just makes Octave look bad.


Dennis Cote <dennisc_hi>
Tue 17 Dec 2024 06:11:09 PM UTC, comment #62: 

This was also reported again in bug #65769. (That other report can probably be closed as a duplicate of this older report.)

Running `path(path())` after creating a new file seems to work around the issue.

Markus Mützel <mmuetzel>
Group administrator
Tue 17 Dec 2024 06:07:02 PM UTC, comment #61: 

thanks for the update Dennis.  just for completeness can you mention the Windows version you're using and where the file location is located (I would assume the default of C:/Users/_username_/... since you said user home directory)

Nicholas Jankowski <nrjank>
Group Member
Tue 17 Dec 2024 05:12:47 PM UTC, comment #60: 

This bug is still present in Octave 9.3.0 on Windows.

-Open Octave GUI
-create a new editor file
-add Octave commands to the script file
-save the file to the current directory (user's home directory)
-switch to the command window
-type the name of the script file as a command
-produces "error: '<filename>' undefined near line 1, column 1"
-quit Octave
-restart Octave
-type the name of the script file as a command
-script executes without error


Dennis Cote <dennisc_hi>
Thu 03 Oct 2024 04:08:16 PM UTC, comment #59: 

ok.  reopening.  we can tie other reports to it / update them if they're identified.

Nicholas Jankowski <nrjank>
Group Member
Thu 03 Oct 2024 02:37:52 PM UTC, comment #58: 

@nrjank
Yeah you're right, it's not reliable.
Here, with (dev) Octave-10.0.0 on Win10, the first try worked fine, the second didn't.

[OT]
In the bug tracker fields I see 9.1.0 for both "Fixed release"  and "Planned release", these fields should be updated.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 03 Oct 2024 01:29:42 PM UTC, comment #57: 

slight correction:  often would be a better descriptor than regularly.  It's not as repeatable as would be nice for an easily replicable bug report.

Nicholas Jankowski <nrjank>
Group Member
Thu 03 Oct 2024 01:27:39 PM UTC, comment #56: 

yes, i see this regularly with 9.2.0 and fairly recent stable builds.  I've gotten used to simply issuing a path(path)) command which usually corrects it.

I think there are a number of bug reports on this issue or closely related ones, i didn't realize this old one was still getting traffic.  before reopening it's probably worth checking for those.

Nicholas Jankowski <nrjank>
Group Member
Thu 03 Oct 2024 12:30:19 PM UTC, comment #55: 


comment #54:

> [~OT]
> Yes this is an oldie :-)
> I'd celebrate it, this is one from the "ergonomy" category and I think quite a few users have hit this bug over the years, with reports scattered over several bug reports (incl. duplicates) and mailing list(s) threads.
>
> But I'm quite sure that there must be still older open bugs, just not listed on Savannah ... some of those might have resurfaced as younger bug reports. Maybe it applies to this one as well.
> I have no clear recollection of when the Octave project started using Savannah. Could be that we used s/th from SourceForge before that.




Nope, this is still happening in Octave 9.2.0. Make a new .m file in a Windows session, try to run it, you will get the very same error, as if the file did not exist.

> There used to be a mailing list "bug-octave@octave.org", in my archive I have emails with that address back to at least 2009. Even older emails mention (IIRC) JWE's former uni affilations but the project might not have had a dedicated bug mailing list then, let alone bug tracker.
> [/OT]
>
> BTW I'd feel a little more sure if nrjank could also confirm the behavior I see. Although releases 8.1.0 and 9.1.0 (dev) clearly behave differently.

Anonymous
Sun 28 May 2023 09:47:05 PM UTC, comment #54: 

[~OT]
Yes this is an oldie :-)
I'd celebrate it, this is one from the "ergonomy" category and I think quite a few users have hit this bug over the years, with reports scattered over several bug reports (incl. duplicates) and mailing list(s) threads.

But I'm quite sure that there must be still older open bugs, just not listed on Savannah ... some of those might have resurfaced as younger bug reports. Maybe it applies to this one as well.
I have no clear recollection of when the Octave project started using Savannah. Could be that we used s/th from SourceForge before that.
There used to be a mailing list "bug-octave@octave.org", in my archive I have emails with that address back to at least 2009. Even older emails mention (IIRC) JWE's former uni affilations but the project might not have had a dedicated bug mailing list then, let alone bug tracker.
[/OT]

BTW I'd feel a little more sure if nrjank could also confirm the behavior I see. Although releases 8.1.0 and 9.1.0 (dev) clearly behave differently.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 28 May 2023 07:31:04 PM UTC, comment #53: 

Thanks for testing.

I guess this bug can finally be closed now (after almost 13 years).
I'm not sure if this is something to celebrate or to mourn about. 😉
That made it the oldest report that was still open afaict.

Closing as fixed in Octave 9.

Markus Mützel <mmuetzel>
Group administrator
Sun 28 May 2023 02:43:33 PM UTC, comment #52: 

(Sorry, took a while as I lost the notification email and had to track down what bug it was about)

With a dev crossbuild from May 24, using the commands from comment #49 in the root of a drive F: on a multipartitioned SSD under Win10:

>> cd f:
>> edit newtestfile
>> newtestfile
>> ls -l
total 38
<snip>
drwxr-xr-x 1 philip None    0 Feb 14  2022 '$RECYCLE.BIN'
-rw-r--r-- 1 philip None 3929 May 25 19:51  128KEY.TXT
drwxr-xr-x 1 philip None    0 Dec 16  2021  DOS_dev
drwxr-xr-x 1 philip None    0 Feb  7  2022 'System Volume Information'
-rw-r--r-- 1 philip None  208 Jan 27  2022  btrfs_UUID.txt
drwxr-xr-x 1 philip None    0 Jan 18 23:46  dev
drwxr-xr-x 1 philip None    0 Dec 14  2021  home
drwxr-xr-x 1 philip None    0 Mar  5 10:16  mingw-binaries
-rw-r--r-- 1 philip None    0 May 28 16:34  newtestfile.m
drwxr-xr-x 1 philip None    0 Nov  7  2022  tmp


so at least on my system this bug seems to have been fixed.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 23 May 2023 08:51:57 PM UTC, comment #51: 

Yes I saw the related discussion elsewhere. I'll prepare a new crossbuild later this week and try again.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 23 May 2023 06:40:57 AM UTC, comment #50: 

Recent changes on the default branch might have affected this behavior (hopefully for the better).

Do you still see this issue with a recent build from the default branch?

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Dec 2022 12:02:49 AM UTC, comment #49: 

this bug is still present in octave 8.0.1 (hg id: 24bd675bceab)

testing on a ntfs local ssd in windows 10:


>> cd d:
>> edit newtestfile (create a new script file and save it)
>> newtestfile
error: 'newtestfile' undefined near line 1, column 1
>> ls -l
total 30
<snip>
drwxr-xr-x 1 Admin None   0 Jan 10  2022 '$RECYCLE.BIN'
drwxr-xr-x 1 Admin None   0 Nov  9 01:02  MapData
drwxr-xr-x 1 Admin None   0 Mar 22  2022  Programs
drwxr-xr-x 1 Admin None   0 Aug  9  2020  Recovery
drwxr-xr-x 1 Admin None   0 Aug  9  2020 'System Volume Information'
drwxr-xr-x 1 Admin None   0 Mar 21  2022  localdata
-rw-r--r-- 1 Admin None   9 Dec  8 18:21  newtestfile.m
drwxr-xr-x 1 Admin None   0 Jan 10  2022  temp
>> newtestfile
error: 'newtestfile' undefined near line 1, column 1



also, trying Markus's stat test, things behave fine in a subfolder:


>> cd temp
>> dir
.   ..
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1670543181
    mtime = 1641824642
    ctime = 1590511359
    blksize = NaN
    blocks = NaN

>> fclose(fopen('testfile.m','w'))
ans = 0
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1670543207
    mtime = 1670543207
    ctime = 1590511359
    blksize = NaN
    blocks = NaN


but in the root of the drive:


>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 315550800
    mtime = 315550800
    ctime = 315550800
    blksize = NaN
    blocks = NaN

>> fclose(fopen('testfile.m','w'))
ans = 0
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 315550800
    mtime = 315550800
    ctime = 315550800
    blksize = NaN
    blocks = NaN

>> ls -l
total 30
<snip>
drwxr-xr-x 1 Admin None   0 Jan 10  2022 '$RECYCLE.BIN'
drwxr-xr-x 1 Admin None   0 Nov  9 01:02  MapData
drwxr-xr-x 1 Admin None   0 Mar 22  2022  Programs
drwxr-xr-x 1 Admin None   0 Aug  9  2020  Recovery
drwxr-xr-x 1 Admin None   0 Aug  9  2020 'System Volume Information'
drwxr-xr-x 1 Admin None   0 Mar 21  2022  localdata
-rw-r--r-- 1 Admin None   0 Dec  8 18:31  newtestfile.m
drwxr-xr-x 1 Admin None   0 Dec  8 18:46  temp
-rw-r--r-- 1 Admin None   0 Dec  8 18:52  testfile.m
>> testfile.m
error: 'testfile' undefined near line 1, column 1


are those time values normal in a root folder?

Nicholas Jankowski <nrjank>
Group Member
Fri 29 Oct 2021 05:15:11 PM UTC, comment #48: 

Thanks.
So, it looks like the mtime of the parent directory didn't update when the file was created.
It is for me when I do the same:

>> format long
>> which test1
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1635525754
    mtime = 1635523631
    ctime = 1635523460
    blksize = NaN
    blocks = NaN

>> fclose(fopen('test1.m', 'w'));
>> stat('.')
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1635527519
    mtime = 1635527519
    ctime = 1635523460
    blksize = NaN
    blocks = NaN

>> which test1
'test1' is a script from the file D:\SVN\Octave\test\octave-2021-10-28-21-39-w64 release of-audio\octave-2021-10-28-21-39-w64\test1.m


What file system (NTFS, FAT32, exFAT, ...) do you use on your drive D:?

Markus Mützel <mmuetzel>
Group administrator
Fri 29 Oct 2021 04:12:11 PM UTC, comment #47: 

Sorry bad read, I thought I had to write the file with the instruction, here is the correct test (I think). The data drive is an additional SSD disk.

>> format long
>> which test1
>> stat('.')

ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1635509742
    mtime = 1635509742
    ctime = 1635509742
    blksize = NaN
    blocks = NaN

>> fclose(fopen('test1.m', 'w'));
>> stat('.')

ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1635509742
    mtime = 1635509742
    ctime = 1635509742
    blksize = NaN
    blocks = NaN

>> which test1

Silvestre <paredes>
Fri 29 Oct 2021 12:51:10 PM UTC, comment #46: 

Thanks for testing. But please run the test in a directory that does not contain `test1.m` before the test.

Markus Mützel <mmuetzel>
Group administrator
Fri 29 Oct 2021 12:32:16 PM UTC, comment #45: 

Hi again:

It must be a problem with the disk drive (D:), I have repeated the process on home disk (C:) and there are no problems....

Octave is installed in home disk (c:) as usual, but data are in data disk (d:).

I will check the data disk (d:) configuration....


Silvestre <paredes>
Fri 29 Oct 2021 12:27:44 PM UTC, comment #44: 


I have logged in from the beginning......


------------------------------------------------------------------------

GNU Octave, version 6.3.0
Copyright (C) 2021 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

>> dir

.   ..

>> edit test1.m
>> dir

.        ..       test1.m

>> test1

error: 'test1' undefined near line 1, column 1

>> type test1.m

error: type: couldn't open '' for reading
error: called from
    type at line 92 column 9

>> path(path());
>> type test1.m

test1.m is the user-defined function defined from: D:\test\test1.m

format long
which test1
stat('.')
fclose(fopen('test1.m', 'w'));
stat('.')
which test1

>> test1

'test1' is a script from the file D:\test\test1.m
ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1635509742
    mtime = 1635509742
    ctime = 1635509742
    blksize = NaN
    blocks = NaN

ans =

  scalar structure containing the fields:

    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1635509742
    mtime = 1635509742
    ctime = 1635509742
    blksize = NaN
    blocks = NaN

'test1' is a script from the file D:\test\test1.m

>> type test1.m

test1.m is the user-defined function defined from: D:\test\test1.m


Silvestre <paredes>
Fri 29 Oct 2021 11:33:15 AM UTC, comment #43: 

Re-starting Octave isn't the solution. I just wanted to see if it is something intrinsic to that file or folder...

Re-reading the discussion, it looks like rehash uses some logic to only re-scan the folders of which it thinks that they have changed.
Does re-creating the load path cache completely with `path(path())` help? (I hope that doesn't use some clever tricks to avoid rehashing paths it thinks it already knows...)

Additionally, IIUC, Mike's suspicion was that the modification date of the parent directory doesn't change. Could you try something like the following in a directory that doesn't contain a 'test1.m' file and show the results here?

format long
which test1
stat('.')
fclose(fopen('test1.m', 'w'));
stat('.')
which test1


Markus Mützel <mmuetzel>
Group administrator
Fri 29 Oct 2021 07:39:59 AM UTC, comment #42: 

Local drive (both Octave and the script)

Yes, I find the file after restart Octave (but I think it is not very elegant and time is wasted)

No, I have the same problem even after using rehash().

Only if I restart OCTAVE or, without restarting, I use the option 'Edit->Set Path->Save options' from the top menu of the GUI, then I can see and use the script.


Silvestre <paredes>
Fri 29 Oct 2021 06:59:01 AM UTC, comment #41: 

Do these files reside on a local drive or a network share?
ISTR that there were missing signals for file updates from UNC shares (maybe also others).

Is the file found on a restart of Octave? Does issuing `rehash()` to manually trigger a load path cache update make a difference?

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Oct 2021 10:40:25 PM UTC, comment #40: 

I have created a simple script call probe.m to show the bug, I enclosed the answer from the system. I'm using GUI Octave (6.3.0)


------------- I can see the file in the directory, using octave dir command

>> dir

.                FUNCIONALIDADES  get_matrix.m     getmat.m         probe.m
..               SCRIPTS          getm.m           pm.m




------------ I can see the content of the file, using octave dos command with command type

>> dos("type probe.m")

AB=randn(2,3);
ans = 0



------------ I cannot see the content of the file if I use octave type command

>> type probe.m

error: type: couldn't open '' for reading
error: called from
    type at line 92 column 9



----------  I cannot run the script from the OCTAVE prompt

>> probe

error: 'probe' undefined near line 1, column 1

Silvestre <paredes>
Wed 27 Oct 2021 06:40:42 AM UTC, comment #39: 

@paredes: Could you please show the exact error message or output you are seeing when calling your script doesn't work?

Markus Mützel <mmuetzel>
Group administrator
Tue 26 Oct 2021 07:13:57 PM UTC, comment #38: 

I have two local drive, the one with the windows system (c:), and another (d:) for data, Octave is installed in the default directory at unit C:. I'm using windows 10 Pro.

I change the working directory to drive d:, and add the path to the OCTAVE one, using addpath.

After using Reload (Set Path from the Edit menu), I can use the functions.

Regards,
 

Silvestre <paredes>
Tue 26 Oct 2021 06:07:14 PM UTC, comment #37: 

@Silvestre - just for reference all of the things that might be relevant: are you working on a local drive, a network drive, are you running Windows and which version, and if so are you in a Onedrive managed folder?


Nicholas Jankowski <nrjank>
Group Member
Tue 26 Oct 2021 05:52:35 PM UTC, comment #36: 

I have the same problem with version 6.3.0

I wrote a scripts, I save it at my working directory, I can see the file with command "dir", I can edit the file with command "edit", but neither I cannot see the file with command "type" and of course I cannot run the script; Yes, if you are asking for, I can do it after restart OCTAVE.

How can I fix it?


Silvestre <paredes>
Sat 23 Feb 2019 11:42:41 AM UTC, comment #35: 

Closing as fixed as per comment #34.
If this behaviour should re-appear, we can re-open this bug or file a new one.

Markus Mützel <mmuetzel>
Group administrator
Fri 22 Feb 2019 08:46:24 PM UTC, comment #34: 

wanted to comment that I cannot recreate the situation from Comment #32 with Octave 5.0.91

Nicholas Jankowski <nrjank>
Group Member
Wed 30 May 2018 07:01:13 PM UTC, comment #33: 

I cannot recreate it with Octave-5.0.0 on Windows 7 and on Windows 10.
In fact it works fine here even with octave-4.2.2 on Windows 10.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 30 May 2018 04:20:23 PM UTC, comment #32: 

I can still recreate the behavior.


>> cd m:\test
>> toto.m
error: 'toto' undefined near line 1 column 1
>> edit toto.m
>> toto
error: 'toto' undefined near line 1 column 1
>> dir
.                         chntpw_1.0-1+b1_i386.deb  reviews
..                        elmerbackset.bat          toto.m
Command Prompt.lnk        elmerset.bat
>> toto
retval =  1
ans =  1
>>


Nicholas Jankowski <nrjank>
Group Member
Wed 30 May 2018 03:45:09 PM UTC, comment #31: 

Just tried the following on Windows 10:

```

>> cd d:\        % toto.m does not exist yet
>> edit toto.m   % create script containing: disp hello
>> toto

```

As reported below, this fails in Octave 4.0 and 4.2 with error 'toto' undefined.

The good news is, it works as expected with Octave 4.4.

Unless someone is able to reproduce the problem with Octave 4.4 on some other version of Windows, this bug can be closed ;-)

Julien Bect <jbect>
Wed 16 Nov 2016 04:55:59 PM UTC, comment #30: 

just noticed this bug, after a similar issue came up and was reported as bug #49203.

https://savannah.gnu.org/bugs/?49203

Nicholas Jankowski <nrjank>
Group Member
Mon 13 Jun 2016 03:21:07 AM UTC, comment #29: 

I like Abhinav's suggestion of only forcing a rehash of a directory known to have changed.  I wouldn't call that a sledgehammer at all.

One way to make it more fine-grained would be to allow the second argument to be a filename rather than a directory.  Then adding a file is very efficient -- presumably much more efficient than doing a rehash of the whole directory based on a timestamp.  The only need for an inefficient whole-directory rehash is that a file may have been added by a program external to (and not triggered by) Octave.

Also, I think you would be looking for "FindFirstChangeNotification", the Windows equivalent to Linux's inotify.  I don't think MinGW supports inotyify.  http://stackoverflow.com/questions/36125844/use-inotify-with-mingw

Lachlan Andrew <lachlan>
Tue 03 May 2016 06:47:56 PM UTC, comment #28: 

We already have a reshash function, but all it does is traverse the directories in the path and look for modification times that are newer than the last timestamp the directory was scanned. This is still failing on Windows in this situation. Adding a way to do some kind of "force rehash" is a sledgehammer that might work around this, but I still think the root issue is something quirky with the way Windows filesystems are working with Octave.

Mike Miller <mtmiller>
Group Member
Tue 03 May 2016 06:41:13 PM UTC, comment #27: 

@Mike: Adding a rehash command doesn't sound all that bad to me.  Certain system shells, like csh, have a rehash command to update internal caches after you have changed the PATH variable.

The root cause seems to be known which is that Octave relies on timestamps, and timestamps on Windows filesystems are not always updated.  I don't think more detective work will help.

If we want to fix the root cause, then I like your suggestion of looking at inotify.  I've never done anything with it though so I can't say how hard it would be.

rehash seems like a nice workaround if we don't want to address the root cause.

Rik <rik5>
Group administrator
Tue 03 May 2016 06:25:30 PM UTC, comment #26: 

No, what we really need to determine is why new files not being found. Is it because the directory timestamp is actually not updating? Is it because something in the MinGW system library translation layer is not working right? Is it because the timestamp resolution isn't fine enough? Is the directory timestamp actually being updated but Octave isn't noticing that somehow? Does it have to do with the type of directory or the type of filesystem used?

We need some detailed tests showing the results of stat(), for example, on the directory containing a new file, and what the system timestamp is when the directory's modified timestamp actually does get updated, if it does at all.

Mike Miller <mtmiller>
Group Member
Tue 03 May 2016 06:11:49 PM UTC, comment #25: 

To solve this issue, i propose to add a new function 'force_rehash(dir_name)' to force a rehash of the dir without checking for timestamp or edit the current rehash so that 'rehash' or 'rehash(false)'  remain as is. But 'rehash(true, dir_name)' could be used to force rehash irrespective of timestamp!
.
This won't be a huge change and will allow users to force a rehash on windows and certainly solve this issue.
.
Should I do the changes and submit a cset? Does anyone have a problem with this approach (just asking as the issue is old and it hasn't been implemented yet)...

Abhinav Tripathi <genuinelucifer>
Mon 02 May 2016 01:40:19 AM UTC, comment #24: 

This issue has resurfaced in the context of the symbolic package:

https://github.com/cbm755/octsympy/issues/431

A valid function file is written to a directory that is already in the load path, and the function is not found until some as-yet-undetermined amount of time later.

Mike Miller <mtmiller>
Group Member
Sun 05 Jan 2014 10:20:03 AM UTC, comment #23: 

Normally, in root dirs there shouldn't be so awfully many files.

I don't know Octave's function/script file loading internals, so apologies if the following is a dumb question; but I wonder, why stat all files? all that seems to be needed is to just stat the called function file in question, and then only once after entering each Octave command (as changing some called function file contents while Octave is accessing it in e.g. a loop wouldn't be a good idea.)

So if this needs to be fixed at all, maybe modding the function/script load logic for Windows systems is the way to go?

I agree with Rik that this can get quite messy.
NTFS isn't a monolithic static file system; there are several versions around. M$ also still has the WinFS looming somewhere, possibly with still other behavior.
On NTFS it is possible to map other drives somewhere in the tree a la *nix mount (on Windows it's called junctions IIRC); we would need to know how those behave as well: as "local" subdirs, or do they behave as remote "root" dirs? in the latter case we'd also need to detect them as such.


Even while this bug is quite old is hasn't seen many confirmations; so I'd also agree with lowering priority/severity until we get more requests.
Repeating myself (see comment #13), having script or function files in root dirs is something that can be avoided.

- IMO on local fixed drives (HDs) it's a bad idea anyway.

- Only on thumb drives and other removable drives, and in some cases on mapped network drives, it can be more reasonable to keep m-files in the root dir.

Perhaps there is a way to detect a directory to be the root of a removable/network device and act accordingly along Jordi's suggestion.
Note that thumb drives, and to a lesser extent network drives, are usually slow; statting files may give a noticeable performance hit.
(I don't know if mapped network drives behave the same as "physical local" drives as regards directory time stamps.)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 05 Jan 2014 05:12:45 AM UTC, comment #22: 

What if we just statted all of the files in the directory instead of only statting the directory? Is this a terrible slowdown, to stat all files in the path directories on every command invocation?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sat 04 Jan 2014 11:22:18 PM UTC, comment #21: 

Yes, confirmed here (I now have a winxp VM with 3.8.0 to test with). The root directory of an NTFS drive seems to have a constant timestamp:


octave:1> format long
octave:2> info = stat ('C:\')
...
    atime =  315550800
    mtime =  315550800
    ctime =  315550800

octave:3> ctime (315550800)
ans = Tue Jan 01 00:00:00 1980
octave:4> edit ('C:\foo.m')
octave:5> info = stat ('C:\')
...
    atime =  315550800
    mtime =  315550800
    ctime =  315550800


So yes this looks unavoidable given the current path caching scheme.

One possibility might be to watch for directory inode changes instead of looking at timestamps. This could use FindFirstChangeNotification on Windows and inotify on Linux-based systems. This would most likely be a major overhaul.

Mike Miller <mtmiller>
Group Member
Sat 04 Jan 2014 11:05:34 PM UTC, comment #20: 

This is all down to the same root cause which is that the directory timestamp is not updated when the directory itself is changed (such as by the addition of a new file).  On FAT filesysems, the directory timestamp is not updated period.  You can work around that by manually using touch.exe to change the timestamp of the directory.  Things are a bit better on NTFS systems, in that directories which are modified have their timestamp updated.  But, this being Microsoft, there are exceptions to that as well.  The root of the file tree is apparently special and just isn't updated.  I tried creating new files, new directories, using touch.exe and the timestamp of the root node is never modified.

The easiest way to see this is from within Octave.  Use


finfo = stat ('e:\')


and replace 'e' by whatever drive letter you are using.

So, the situation just sort of sucks on Microsoft file systems.

It's probably possible to disable the caching code in Octave (make sure this is only on Windows machines), but the performance hit might be unacceptable.  Basically, any time a function wasn't already compiled and in the symbol table, Octave would need to do a full search of every single directory on the path.  This would also happen everytime someone entered a typo as well like 'dirt' for 'dir' since Octave couldn't know that you didn't mean to call a function that it doesn't know about.


Rik <rik5>
Group administrator
Sat 04 Jan 2014 10:09:34 PM UTC, comment #19: 

Re-reading comments #7 and #8, you'll see that this is primarily about the directory timestamp, not necessarily the file timestamp. So Octave is expecting the timestamp of the containing directory to be updated. Do drive top-level directories have timestamps in Windows, and are they updated when new files are created at the top level?

What does


format long
info = stat ('X:\')


show before and after creating a new m-file?

Mike Miller <mtmiller>
Group Member
Sat 04 Jan 2014 10:02:24 PM UTC, comment #18: 

Forgot to add screen session pic; attached.


Philip Nienhuis <philipnienhuis>
Group Member
Sat 04 Jan 2014 10:00:55 PM UTC, comment #17: 

Sorry, I need to be a bit more exact:

do:
"start Octave"
(or "start octave-cli")
.... from that same cmd32 window.

FYI, "start octave" will detach an octave session from that command window. While you're fiddling in Octave, from that cmd32 window you can run "touch".

============
Anyway I've tried this myself with Octave-3.9.0+ and I get the same as the OP. Screen shot of session attached, just to show.
Like the OP I tried it on an NTFS drive (X: in my case)
"touch"ing the file (after Octave command #7-2) doesn't help.

BTW I'm intrigued by the error msg:

octave:7> type test2.m
error: type: couldn't open '' for reading


i.e. Octave seems to forget the file name although it was entered on the command line.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 04 Jan 2014 07:27:28 PM UTC, comment #16: 

@comment #15:

Au contraire, touch.exe does (extremely) probably exist but it's in your <OCTAVE_HOME>/bin directory. IOW in bin/ in the directory where you've installed Octave.
AFAIK it's included in all MXE-built MinGW 3.8.0 binaries.

You could (in a Command window, cmd32.exe) do something like:

set PATH=%PATH%;/full/path/to/Octave/directory/bin

and then start Octave (from that same cmd32 window).

Philip Nienhuis <philipnienhuis>
Group Member
Sat 04 Jan 2014 06:26:45 PM UTC, comment #15: 

The command touch does not exist on Windows

A substitute to this command is : copy /b file +,,
(found on http://stackoverflow.com/questions/51435/windows-version-of-the-unix-touch-command), but it doesn't solve the problem.



J-D Bonjour <jdb>
Sat 04 Jan 2014 05:47:13 PM UTC, comment #14: 

Does it work if you use touch.exe to update the file's modification time?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Sat 04 Jan 2014 05:02:03 PM UTC, comment #13: 

Yes I'm following but a bit short of time lately - maybe tonight or otherwise tomorrow I'll check. & I also have to (re)build 3.8.0 first.

From what I've read so far I inferred that Octave relies on subdirectory timestamps, not individual function-/script-file timestamps.
Very probably -if not undoubtedly- for good reason (not hard to guess); but a drawback is this sort of issues.

A workaround is to avoid root dirs. Even on thumb drives (USB sticks) that would be a good way.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 04 Jan 2014 04:31:41 PM UTC, comment #12: 

Sorry, it doesn't work for me on an NTFS drive (see my session below) !
Philip Nienhuis, could you also check, please ?

Jean-Daniel


octave:1> ver

GNU Octave Version 3.8.0
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-5.1 Windows XP Service Pack 3 i686
% so I'm working on Windows XP with the 3.8.0 Octave bundle
% from http://octave.osuv.de/3.8/windows/octave-3.8.0-1-portable.zip

octave:2> system('chkdsk M: /i')

The type of the file system is NTFS
...
% so the filesystem of my M: drive is NTFS !

octave:3> cd M:\octave_test  % going to a sub-directory
octave:4> edit test1.m
% new file, inserting the line: disp('Hello from sub-dir of drive M:')
octave:5> test1

Hello from sub-dir of drive M:
% so on a sub-dir it works allways

octave:6> cd M:\   % going to the root of this NTFS drive
octave:7> edit test2.m
% new file, inserting the line: disp('Hello from root of drive M:')
octave:8> ls

[octave_test]  test2.m
% the created script is visible, but...

octave:9> type test2.m

error: type: couldn't open '' for reading
error: called from:
error:   ...\type.m at line 85, column 9

octave:10> test2

error: 'test2' undefined near line 1 column 1

% * And now restarting Octave *
octave:1> cd M:\
octave:2> test2

Hello from root of drive M:
% so it works after restarting Octave !

octave:3> type test2.m

test2.m is the user-defined function defined from: M:\test2.m
 
disp('Hello from root of drive M:')

octave:4> edit test2.m
% adding the line: disp('Second line added')
octave:5> test2

Hello from root of drive M:
Second line added


J-D Bonjour <jdb>
Sat 04 Jan 2014 04:14:46 AM UTC, comment #11: 

I just reformatted a USB memory stick to use NTFS instead of the default FAT32 and Octave works perfectly with it.  So the diagnosis about timestamps is accurate.

John, I was able to check the file system type by double-clicking "My Computer" to get a list of disk drives.  If I right-click on a disk drive and then click on Properties it brings up a new tabbed window.  In the General tab there is an entry called File System.

Rik <rik5>
Group administrator
Sat 04 Jan 2014 02:10:48 AM UTC, comment #10: 

I'm unable to reproduce the problem with Octave 3.8.0 running on Windows 7 in a virtual machine.  I tried the GUI and the CLI version.

I assume that this is with an NTFS filesystem, but I don't know for sure.  How do I check?

John W. Eaton <jwe>
Group administrator
Sat 04 Jan 2014 01:04:21 AM UTC, comment #9: 

No, sorry, the problem also occurs on NTFS partitions ! So it's not a good idea to lower the priority

J-D Bonjour <jdb>
Fri 03 Jan 2014 10:53:27 PM UTC, comment #8: 

This is definitely bad Microsoft mojo.  This microsoft support brief (http://support.microsoft.com/kb/299648) explains that NTFS directory timestamps are updated when directory contents change, but FAT formatted filesystems do not update directory timestamps when contents change.

My guess is that most modern installs of Windows have an NTFS partition for C:\ which explains why it works on the root partition.  Other drive letters are typically things like USB memory sticks which are probably formatted with FAT filesystems which explains why it tends not to work on them.

I'm lowering the priority for this bug.  Overhauling a huge amount of Octave directory code to deal with Microsoft's bad design is not my first choice of things that need improvement in Octave.

Rik <rik5>
Group administrator
Fri 03 Jan 2014 10:25:04 PM UTC, comment #7: 

Very definitely confirmed.  Octave seems to be caching the contents of a directory on start-up and then never updating the cache.  This could be down to differences in how the operating system updates the inode timestamp for the directory.

On Linux, creating a new file in a directory updates the timestamp.  I think Octave is comparing the current directory timestamp against the cached timestamp to figure out if it needs to go and re-read the directory.

On Windows, creating a new file in a directory does not change the timestamp--I know because I tried.  However, I have the UNIX tool touch.exe installed and when I touch the directory to bring the timestamp up to the current time then Octave correctly finds the new m-files.

This sequence worked:


cd e:\
mkdir tmptst
cd tmptst
edit junk.m
## Add some code to junk.m in the editor and then quit
which junk.m
## Returns nothing
## Now, in another shell window execute touch e:\tmptst
which junk.m
'junk.m' is the file e:\tmptst\junk.m


Seems like it might require a lot of O/S specific code to solve this one.

Rik <rik5>
Group administrator
Fri 03 Jan 2014 08:46:21 PM UTC, comment #6: 

Yes, this problem is still present on Windows. Tested now with the octave-3.8.0-1-portable.zip packaging distributed on http://octave.osuv.de/3.8/windows/

JDB

J-D Bonjour <jdb>
Fri 03 Jan 2014 09:09:56 AM UTC, comment #5: 

Thanks for reminding me, I'll check it out.

[Little bit OT]
A similar problem I hit with recent dev versions (3.7.7 & 3.9.0 and the two 3.8.0 release candidates) is that editing/debugging functions in private/ dirs leads to similar behavior (on MinGW):
Octave suddenly doesn't seem to be able to find certain private/functions anymore (while other private/ functions weren't affected). Adding the private subdit to the load path (as the GUI editor helpfully suggests) didn't help. Only a restart helps.
But as this behavior was erratic, and because I don't know the exact rules for the search path as regards private subdirs, I thought I was probably fubarring up myself so I didn't file a bug report.
After all, things work OK as long as functions in private subdirs aren't touched.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 02 Jan 2014 09:11:57 PM UTC, comment #4: 

Is this problem still present in Octave 3.8.0?

John W. Eaton <jwe>
Group administrator
Thu 17 Oct 2013 08:11:45 PM UTC, comment #3: 

Octave 3.7.7+ MXE GUI built for MinGW, installed on drive X, and Octave-3.6.7+ MXE CLI (ditto):

With either script or function files, it doesn't even work in a subdir of root:

octave-cli.exe:1> pwd
ans = X:\Octave\octave-3.7.6+_MXE
octave-cli.exe:2> cd f:/tmp
octave-cli.exe:3> edit script.m
octave-cli.exe:5> dir script.m
script.m
octave-cli.exe:6> script
error: 'script' undefined near line 1 column 1
octave-cli.exe:6> rehash
octave-cli.exe:7> script
error: 'script' undefined near line 1 column 1
octave-cli.exe:7> clear -f
octave-cli.exe:8> script
error: 'script' undefined near line 1 column 1
octave-cli.exe:8>
:
:
octave-cli.exe:8> cd /
octave-cli.exe:9> pwd
ans = f:\
octave-cli.exe:10> edit script2.m
octave-cli.exe:11> dir *.m
script2.m
octave-cli.exe:12> script2
error: 'script2' undefined near line 1 column 1
octave-cli.exe:12>


After restarting, Octave behaves even stranger:


octave-cli.exe:1> cd f:\tmp
octave-cli.exe:2> dir *.m
funcfil.m                  strread_bitw_regexp.m      textread.m
script.m                   strread_bitwidth.m         textscan.m
strread.m                  strread_bitwidth_regexp.m
octave-cli.exe:3> funcfil    ## Works OK
Hello world!

octave-cli.exe:4> script     ## does nothing
octave-cli.exe:5> type script.m
script.m is the user-defined function defined from: .\script.m

disp ("Hello World!\n")';

octave-cli.exe:6>
octave-cli.exe:7> cd /
octave-cli.exe:8> dir *.m
funcfil2.m  script2.m
octave-cli.exe:9> script2    ## Works OK;
Script 2

octave-cli.exe:10> funcfil2
octave-cli.exe:11> funcfil2
octave-cli.exe:12> type funcfil2
funcfil2 is the user-defined function defined from: f:\funcfil2.m

function [retval] = funcfil2 ()

        disp ("Funcfil2\n")';

endfunction

octave-cli.exe:13> type script2
script2 is the user-defined function defined from: f:\script2.m

disp ("Script 2\n");

octave-cli.exe:15>which funcfil2
'funcfil2' is a function from the file f:\funcfil2.m


Striking is that it works upon restart for functions but not for scripts in a subdir, and the other way round in the root dir.

Could these be MinGW bugs (in the gcc runtime libraries)?

Philip Nienhuis <philipnienhuis>
Group Member
Thu 17 Oct 2013 06:34:28 PM UTC, comment #2: 

Is this still present in the development version that is about to become the 3.8 release?

Rik <rik5>
Group administrator
Fri 03 Feb 2012 11:16:47 AM UTC, comment #1: 

Still present in 3.6.0 MinGW

Philip Nienhuis <philipnienhuis>
Group Member
Sun 19 Sep 2010 10:42:38 PM UTC, original submission:  

On Octave MinGW32 for Windows versions 3.2.0 to 3.2.4, when the user current directory is the root of a Windows partition other than C:\ (e.g. D:\, E:\ ...), the m-files (scripts or functions) created by the user during the session (with command "edit" or with other editors) are not usable : when invoqued, the following message is returned : error: '<script>' undefined near line xxx column 1.

Its very strange, because the command "dir" sees these m-files created during the session, and if I restart Octave I am able to use them... but not new scripts/functions created during the session.
 
Example :

> cd T:\test
> edit script.m
>    % creating script containing line:  disp('hello world !')
> script

hello world !

>    % so it works !
>
> cd ..  % going to the root of this filesystem T:\
> pwd

ans = T:\

> edit script2.m
>    % creating script containing line:  disp('hello again')
> script2

error: `script2' undefined near line 7 column 1

>    % doesn't work, but the script is here :
> dir

 .        ..       script2.m

> quit
>
>    % new Octave session
> cd T:\
> script2

hello again

>    % now it works, because it's a new Octave session


J-D Bonjour <jdb>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #56779:  Change_or_Add.png added by dennisc_hi (38KiB - image/png)

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dennisc_hi (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by paredes (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jbect (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by genuinelucifer (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Updated the item)
  • -email is unavailable- added by jdb (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 group members can vote.

     

    Follow 40 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-02-01 rik5 Fixed ReleaseNone 9.4.0
        Planned Release10.1.0 9.4.0
    2025-02-01 rik5 Open/ClosedOpen Closed
    2025-02-01 rik5 StatusReady For Test Fixed
    2025-01-17 dennisc_hi Attached File- Added Change_or_Add.png, #56779
    2025-01-06 mmuetzel StatusPatch Submitted Ready For Test
        Planned ReleaseNone 10.1.0
    2024-12-29 mmuetzel Attached File- Added bug31080-rehash-load-path-on-file-save.patch, #56724
        StatusConfirmed Patch Submitted
    2024-12-29 mmuetzel Dependencies- bugs #65769 is dependent
    2024-10-03 nrjank Planned Release9.1.0 None
    2024-10-03 nrjank StatusNeed Info Confirmed
        Open/ClosedClosed Open
        Fixed Release9.1.0 None
    2024-10-03 nrjank StatusFixed Need Info
    2023-05-28 mmuetzel StatusNeed Info Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 9.1.0
        Planned ReleaseNone 9.1.0
    2023-05-15 philipnienhuis Carbon-Copy- Added philipnienhuis
    2021-10-29 philipnienhuis Carbon-CopyRemoved 78941 -
    2021-10-29 mmuetzel StatusFixed Need Info
        Open/ClosedClosed Open
    2021-10-29 rik5 Carbon-CopyRemoved 72865 -
    2019-02-23 mtmiller Carbon-CopyRemoved 80942 -

    Back to the top

    Powered by Savane 3.14-962f.
    Corresponding source code