[Octave-bug-tracker] [bug #31080] User scripts or functions created during a session on Windows are not found

[Dennis Cote]

Follow-up Comment #82, bug #31080 (group octave):

[comment #81 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?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?31080>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature