bugGNU Octave - Bugs: bug #64193, Octave 8.2.0: massive problems...

 
 

bug #64193: Octave 8.2.0: massive problems with file change notifications under WIN10

Submitter:  Siegbert Steinlechner <sigi_s>
Submitted:  Sun 14 May 2023 07:22:34 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * stable Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 30 May 2023 07:10:14 AM UTC, comment #13: 

Thanks. So, it doesn't look like there are softlinks (to other discs or shares).

To limit the number of (generally slow) disc accesses, Octave monitors the modification time of the folders in its load path (not the modification time of each individual file).
That is the `mtime` in the result of the `stat` command. You'd need to find out why it doesn't update for you (or only with a delay?).

As a workaround, you might be able to use `path(path)`. That should re-initialize the load path from scratch and should scan the content of all folders in the load path for .m files and loadable libraries (.oct and .mex).

> I guess, when the file explorer is running, the update rate of the file status increases. Any comments to this behavior?


I've never heart of that before. But I wouldn't be surprised if MS used some undocumented(?) features in their products.

Markus Mützel <mmuetzel>
Group administrator
Mon 29 May 2023 06:16:14 PM UTC, comment #12: 

comment#9:

>Do you use any antivirus or other "security" software? If yes, which? Does it make a difference if you (temporarily?) disable that software?


No, only the WIN10 built-in antivirus software.

The time between file save and run-command definitely matters on my system. I guess, after the run-command, Octave checks whether the file in memory has been changed on harddisk. But the true status of the file is available only after ~3 seconds. If I run the file within 1 second after saving it, the old content in memory is used.

comment #11:

>> canonicalize_file_name('D:/Userdaten/Octave/Euler/Euler800_899/Euler833')

ans = D:\Userdaten\Octave\Euler\Euler800_899\Euler833

>> canonicalize_file_name('D:/Userdaten/Octave/Euler/Euler800_899/Euler833/Test.m')

ans = D:\Userdaten\Octave\Euler\Euler800_899\Euler833\Test.m

comment #8:

> Now I made a strange observation: when the WIN10 file explorer is opened, showing the parent folder of the m-File, I can't reproduce the error. If I close the file explorer, the error happens again if there is less than ~1 second between file save and running the file.


I guess, when the file explorer is running, the update rate of the file status increases. Any comments to this behavior?

Siegbert Steinlechner <sigi_s>
Mon 29 May 2023 09:22:48 AM UTC, comment #11: 

Also to make sure there is no symlinking at play here, could please show the results for the following commands in Octave (please adapt to the actual path and file names)?

canonicalize_file_name('D:\path\to\the\parent\folder')
canonicalize_file_name('D:\path\to\the\parent\folder\script.m')


Markus Mützel <mmuetzel>
Group administrator
Mon 29 May 2023 09:17:29 AM UTC, comment #10: 

You wrote that the modification time before and after the save operations changes. But the result that you show for `stat` before and after the save look exactly the same to me (in particular `mtime`).
Is that a copy-paste error?

Markus Mützel <mmuetzel>
Group administrator
Mon 29 May 2023 09:11:32 AM UTC, comment #9: 

At least in theory, the time between saving the file and running it shouldn't make a difference when it comes to the resolution of file modification times. For that, only the time between two subsequent file saves matters.

If the time between saving the file and running it makes a difference for you, there might be some unexpected file system buffering going on in the background.
I'm not sure what might be causing that. Do you use any antivirus or other "security" software? If yes, which? Does it make a difference if you (temporarily?) disable that software?

Markus Mützel <mmuetzel>
Group administrator
Mon 29 May 2023 08:10:09 AM UTC, comment #8: 

Now I made a strange observation: when the WIN10 file explorer is opened, showing the parent folder of the m-File, I can't reproduce the error. If I close the file explorer, the error happens again if there is less than ~1 second between file save and running the file.

Siegbert Steinlechner <sigi_s>
Mon 29 May 2023 08:06:46 AM UTC, comment #7: 

Good question. The error happens, when I save the file in the editor and start it immediately (after ~1 second) using the "run"-button. If the error has happened, pressing the "run" button reproduces the error. In this case, i have to modify the file, store ist and wait ~3 seconds.

"Is it a file in a 'private', `+`, or `@` folder?" => no.

"Does the modification time of the folder containing the file change when you save the file?" => yes

stat before:
    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1685344063
    mtime = 1684048284
    ctime = 1659130481
    blksize = NaN
    blocks = NaN

stat after
    dev = 3
    ino = 0
    mode = 16895
    modestr = drwxrwxrwx
    nlink = 1
    uid = 0
    gid = 0
    rdev = 3
    size = 0
    atime = 1685344063
    mtime = 1684048284
    ctime = 1659130481
    blksize = NaN
    blocks = NaN

Siegbert Steinlechner <sigi_s>
Wed 24 May 2023 10:50:49 AM UTC, comment #6: 

Hmmm...

Afaict, the modification time resolution of some file systems on Windows is a couple of seconds.
Does the error only occur if you save the file in rapid succession? Or does it also happen if there is a longer time period from when the file was previously saved?

Is it a file in a 'private', `+`, or `@` folder?

Does the modification time of the folder containing the file change when you save the file?
What does `stat` return for that parent folder before and after you saved it? Could you please show the output of the following commands (adapt to the actual path name) before and after a save operation that wasn't detected?

format long
stat('D:\path\to\the\parent\folder')


Markus Mützel <mmuetzel>
Group administrator
Wed 24 May 2023 09:24:42 AM UTC, comment #5: 

Files are stored in in a subfolder of local disk D:

Siegbert Steinlechner <sigi_s>
Mon 22 May 2023 08:41:11 AM UTC, comment #4: 

Are those files stored in the root directory of that disc? Or in a folder?

Markus Mützel <mmuetzel>
Group administrator
Mon 15 May 2023 03:50:44 PM UTC, comment #3: 

this is a longstanding known issue that is related to how windows updates the Modified date for files and folders and inconsistencies in how it reliably does so whether you are on the system drive, a secondary drive, or a network drive. Seems to be independent of if its a NTFS or FAT filesystem.

see bug #31080  (octave's oldest open bug report),

bug #49203 (closed, but related more to the editor not finding the file)

there were a few others, i don't know if we've always found reliable workarounds.

Nicholas Jankowski <nrjank>
Group Member
Mon 15 May 2023 06:36:22 AM UTC, comment #2: 

File system is NTFS

Siegbert Steinlechner <sigi_s>
Sun 14 May 2023 08:36:12 PM UTC, comment #1: 

What is the file system on drive D?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 14 May 2023 07:22:34 PM UTC, original submission:  

Some days ago I updated Octave 7 to Octave 8.2.0.

Now I have the problem that changes in the editor window (after saving) are often not notified correctly to the interpreter. When trying to run the changed file, very often the old content is used. Sometimes it helps to insert a blank somewhere in the file, delete the blank and save the file. Eventually then the new content of the file is run (or not).

I had this behavior sometimes also in older versions of Octave (eg. version 7), but not so often as with Octave 8.2.0. Perhaps I have to go back to version 7.

The m-files are stored on a local drive D:

Siegbert Steinlechner <sigi_s>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by sigi_s (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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-05-22 mmuetzel StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code