bugGNU Octave - Bugs: bug #29878, Octave does not detect new script...

 
 

bug #29878: Octave does not detect new script files when using external drive

Submitted by:  Jake <epy>
Submitted on:  Thu 13 May 2010 08:30:08 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: 3.2.2Operating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Tue 18 May 2010 07:21:40 PM UTC, comment #21:

Building on Windows systems has been a pain lately as evidenced by a lot of traffic on the octave-maintainers list about the correct flags, changes to gnulib, etc.

I'll close this bug and it can be re-opened if the next release doesn't, in fact, solve the problem.

Rik <rik5>
Project Administrator
Tue 18 May 2010 07:06:04 PM UTC, comment #20:

How hard is it to build on Windows? The latest build available from Octave-Forge is 3.2.4. I've never built anything on Windows before without the help of an IDE. I'm only familiar with compiling at the command-line in Linux.

If you guys are sure this is the same problem and that it's already been fixed then that's fine with me.

Jake <epy>
Tue 18 May 2010 07:00:29 PM UTC, comment #19:

Can this bug be marked as fixed and closed?

The patch already exists in the development branch. For completeness it would be nice for the reporter to verify that the development code doesn't have the problem. However, that might be more than Jake wants to take on in which case we can just close the bug.

Rik <rik5>
Project Administrator
Mon 17 May 2010 05:16:20 PM UTC, comment #18:

> He just said it's not what I'm seeing if I'm running 3.2.2, which I am on both Ubuntu and Windows.


What I meant was I (incorrectly) thought you were running a version of octave that was already fixed for this problem. The entire 3.2 series doesn't (and probably won't have the fix).

In theory there may be an additional problem with the fixed version (that is not in 3.2.2) but nobody's been able to produce that problem yet. I got confused and thought you had finally figured out how to trigger the possible problem.

If you build the development sources or wait for 3.4 to be released this problem will probably go away. I don't think the-powers-that-be intend to release another 3.2 series.

Sorry for the confusion.

Judd Storrs <judd>
Mon 17 May 2010 05:07:22 PM UTC, comment #17:

FYI John made the fix. I just stink at web-form copy editing ;)

Judd Storrs <judd>
Mon 17 May 2010 05:06:19 PM UTC, comment #16:

He just said it's not what I'm seeing if I'm running 3.2.2, which I am on both Ubuntu and Windows.

Jake <epy>
Mon 17 May 2010 05:00:32 PM UTC, comment #15:

If Judd's fix is only in the development branch then it sounds like the next step is to build from source if at all possible.

Rik <rik5>
Project Administrator
Mon 17 May 2010 04:24:49 PM UTC, comment #14:

The fix I fix happened almost a year ago in the development branch but just barely after 3.2.0 was released. The fix has not been ported back to the stable branch because it breaks the 3.2 ABI. The 2 sec issue may or may not be an issue in the development branch but it's definitely not what you're seeing if you're running 3.2.2.

Judd Storrs <judd>
Mon 17 May 2010 03:40:25 PM UTC, comment #13:

The hard drive is NTFS, the external thumb drive is FAT32. I have an NTFS formatted external that I can try at home.

I think the problem is much deeper than that. The problem is not simply that Octave doesn't pick up the new file for a few seconds, you can literally sit there all day and keep trying to run that new function file you created but it's just not going to work until you restart Octave.

Jake <epy>
Mon 17 May 2010 02:58:46 PM UTC, comment #12:

Maybe external drives are handled differently so that they don't get corrupted when the get suddenly yanked out "unsafely". Internal drives could get a kernel emulation layer that makes them behave more like NTFS. This could make sense.

Judd Storrs <judd>
Mon 17 May 2010 02:51:39 PM UTC, comment #11:

> I don't see how this is relevant, I was referring to script files, not data files.


Ultimately I think it's the modification times stored in the file system that matter. I was using save because I don't know if touch exists on windows.

Do you have any explanation why it would be different for an external FAT drive relative to an internal FAT drive? Are you certain your internal drives are not NTFS?

The stat()'s indicate that time stamping should be working with the exception that perhaps octave's time resolution is wrong for this drive. All the mtimes are even numbers (even when the ctime is odd and even after an odd delay) which may indicate that the limit should be two seconds for FAT on Windows. Often it looks like the ctime has been rounded up to the next even number.

Are you able to compile octave? I suspect changing time_resolution in liboctave/file-stat.h to 2.0 seconds instead of 1.0 seconds may solve the problem.

Judd Storrs <judd>
Mon 17 May 2010 02:03:14 PM UTC, comment #10:

I don't see how this is relevant, I was referring to script files, not data files.

octave-3.2.2.exe:2:E:\Documents\OSU\ME250\Homework

> format long

octave-3.2.2.exe:3:E:\Documents\OSU\ME250\Homework

> a=100

a = 100
octave-3.2.2.exe:4:E:\Documents\OSU\ME250\Homework

> stat(".")

ans =
{
dev = 4
ino = 0
mode = 16895
modestr = drwxrwxrwx
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 0
atime = 1273809600
mtime = 1270639044
ctime = 1273011432
}

octave-3.2.2.exe:5:E:\Documents\OSU\ME250\Homework

> save test1.mat a

octave-3.2.2.exe:6:E:\Documents\OSU\ME250\Homework

> stat(".")

ans =
{
dev = 4
ino = 0
mode = 16895
modestr = drwxrwxrwx
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 0
atime = 1273809600
mtime = 1270639044
ctime = 1273011432
}

octave-3.2.2.exe:7:E:\Documents\OSU\ME250\Homework

> sleep(5)

octave-3.2.2.exe:8:E:\Documents\OSU\ME250\Homework

> stat(".")

ans =
{
dev = 4
ino = 0
mode = 16895
modestr = drwxrwxrwx
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 0
atime = 1273809600
mtime = 1270639044
ctime = 1273011432
}

octave-3.2.2.exe:9:E:\Documents\OSU\ME250\Homework

> save test2.mat a

octave-3.2.2.exe:10:E:\Documents\OSU\ME250\Homework

> stat(".")

ans =
{
dev = 4
ino = 0
mode = 16895
modestr = drwxrwxrwx
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 0
atime = 1273809600
mtime = 1270639044
ctime = 1273011432
}

octave-3.2.2.exe:11:E:\Documents\OSU\ME250\Homework

> stat("test1.mat")

ans =
{
dev = 4
ino = 0
mode = 33206
modestr = -rw-rw-rw-
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 125
atime = 1274068800
mtime = 1274104960
ctime = 1274104959
}

octave-3.2.2.exe:12:E:\Documents\OSU\ME250\Homework

> stat("test2.mat")

ans =
{
dev = 4
ino = 0
mode = 33206
modestr = -rw-rw-rw-
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 125
atime = 1274068800
mtime = 1274104984
ctime = 1274104982
}

octave-3.2.2.exe:13:E:\Documents\OSU\ME250\Homework

>

Jake <epy>
Fri 14 May 2010 10:50:58 PM UTC, comment #9:

I won't have access to Windows until Monday.

I have confirmed that the same version on Linux reflects changes to the hard disk and external drives, so this is a Windows specific issue for sure.

When a function is called, I imagine that the program checks for a function that's already defined first and then checks if there's a script file in paths matching that name. If this is the case, then it's not Octave's fault obviously.

In any case, I'm guessing it's just Windows not reporting the presence of a new file and then the question is, is there a way to refresh that info. I would think that just checking if a file exists would be sufficient, but I don't know how Octave uses Windows' disk I/O, so.

Jake <epy>
Fri 14 May 2010 08:38:02 PM UTC, comment #8:

Thanks, I forgot that it's the directory that is checked. Can you try this one:

format long
a = 100
stat(".")
save test1.mat a
stat(".")
sleep(5)
stat(".")
save test2.mat a
stat(".")
stat("test1.mat")
stat("test2.mat")

Judd Storrs <judd>
Fri 14 May 2010 06:08:58 PM UTC, comment #7:

octave-3.2.2.exe:1:E:\Documents\OSU\ME250\Homework

> a=100

a = 100
octave-3.2.2.exe:2:E:\Documents\OSU\ME250\Homework

> save test1.mat a

octave-3.2.2.exe:3:E:\Documents\OSU\ME250\Homework

> sleep(5)

octave-3.2.2.exe:4:E:\Documents\OSU\ME250\Homework

> save test2.mat a

octave-3.2.2.exe:5:E:\Documents\OSU\ME250\Homework

> format long

octave-3.2.2.exe:6:E:\Documents\OSU\ME250\Homework

> stat("test1.mat")

ans =
{
dev = 4
ino = 0
mode = 33206
modestr = -rw-rw-rw-
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 125
atime = 1273809600
mtime = 1273860508
ctime = 1273860507
}

octave-3.2.2.exe:7:E:\Documents\OSU\ME250\Homework

> stat("test2.mat")

ans =
{
dev = 4
ino = 0
mode = 33206
modestr = -rw-rw-rw-
nlink = 1
uid = 0
gid = 0
rdev = 4
size = 125
atime = 1273809600
mtime = 1273860522
ctime = 1273860521
}

octave-3.2.2.exe:8:E:\Documents\OSU\ME250\Homework

>


The drive is formatted with FAT32.

Jake <epy>
Fri 14 May 2010 02:33:41 PM UTC, comment #6:

Can you try this somewhere on the external FAT drive and post the output:

a = 100
save test1.mat a
sleep(5)
save test2.mat a
format long
stat("test1.mat")
stat("test2.mat")

Judd Storrs <judd>
Fri 14 May 2010 02:08:18 PM UTC, comment #5:

Do you happen to have an external drive formatted with NTFS? If so, does octave detect file changes on that drive under Windows?

Judd Storrs <judd>
Fri 14 May 2010 02:00:07 PM UTC, comment #4:

Yes

> path

Octave's search path contains the following directories:

.
C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\oct\i686-pc-mingw32
C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\oct\api-v37\i686-pc-mingw32
C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\oct\i686-pc-mingw32
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\site\m
C:\Octave\3.2.2_gcc-4.3.0\share\octave\site\api-v37\m
C:\Octave\3.2.2_gcc-4.3.0\share\octave\site\m
C:\Octave\3.2.2_gcc-4.3.0\share\octave\site\m\startup
C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\oct\i686-pc-mingw32
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\audio
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\deprecated
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\elfun
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\general
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\geometry
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\help
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\image
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\io
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\linear-algebra
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\miscellaneous
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\optimization
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\path
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\pkg
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\plot
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\polynomial
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\set
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\signal
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\sparse
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\specfun
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\special-matrix
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\startup
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\statistics
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\statistics\base
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\statistics\distributions
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\statistics\models
C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\statistics\tests

Jake <epy>
Fri 14 May 2010 01:06:22 PM UTC, comment #3:

What about path()? Does it show properly "." as the first entry?

Jaroslav Hajek <highegg>
Fri 14 May 2010 11:17:00 AM UTC, comment #2:

I have only confirmed this bug on Windows, I can't speak for Linux (yet).

It doesn't read the new file within ANY amount of time, you absolutely must restart the program in order to get it to recognize that a new file is present.

Jake <epy>
Thu 13 May 2010 08:42:07 PM UTC, comment #1:

I think this is related:

http://permalink.gmane.org/gmane.linux.debian.devel.bugs.general/628626

I believe FAT drives have a 2 second time resolution (possibly linux emulates finer resolution for FAT drives) and that octave currently only checks for changes with a 1 second resolution.

Judd Storrs <judd>
Thu 13 May 2010 08:30:08 PM UTC, original submission:

When using Octave in a folder on an external drive (thumb drive), it doesn't seem to detect new script files unless you restart the program. I have tried calling rehash() to see if that would do it, but restarting the program is the only way I can get Octave to see that there is a new script file present.

Steps to reproduce:
1. Insert thumb drive
2. Start Octave
3. Browse to a folder on thumb drive
4. Create new function file in that folder
5. Try and run it, it should give you the undefined error (on Windows anyway)

As stated in the subject, Octave has no problem detecting new script files in folders on the local hard disk.

Jake <epy>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by highegg (Posted a comment)
  • -unavailable- added by judd (Posted a comment)
  • -unavailable- added by epy (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 18 May 2010 07:21:40 PM UTCrik5StatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1