Tue 02 Jun 2015 04:47:31 PM UTC, comment #9:
Retagging release from 4.0.0-rc3 to 4.0.0.
|
Fri 17 Apr 2015 06:48:14 PM UTC, comment #8:
Re-titling report to the correct issue. This is something that Octave will probably leave to Gnulib or MinGW as the upstream provider of the stat() function.
|
Sun 12 Apr 2015 09:51:10 PM UTC, comment #7:
Some background (but I am no expert, this is just from my own experience):
AFAIK NTFS junctions and (sym|hard)links weren't really meant for normal users, at least until fairly recently; but rather for sysadmins to enable them to manage a.o., distributed file systems.
There are quite a few varieties of these "links", each with their own pros and cons, each depending on Windows and NTFS versions.
So I'm not surprised that Octave/MSYS/mingw functions have problems there, and I'm especially unsure if it's realistic to pursue exact *nix-like behavior. If it can be done at all it might only work on the most recent NTFS versions (i.e., Windows versions).
A little more info is e.g., here:
http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
here:
http://stackoverflow.com/questions/9042542/what-is-the-difference-between-ntfs-junction-points-and-symbolic-links
and from my old bookmark collection:
https://support.microsoft.com/en-us/kb/205524/ and https://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
(but none of these explicitly touch upon the differences between NTFS/driver/Windows versions)
|
Sun 12 Apr 2015 02:22:16 PM UTC, comment #6:
Cool, it would be awesome if you could work up some minimal working examples for these defects and report to the Gnulib project, which is I think where the stat and lstat functions would be coming from for Windows.
|
Sun 12 Apr 2015 02:03:39 PM UTC, comment #5:
I have found more problems with stat. Here is the current list:
- stat does not follow symlinks in NTFS
- stat does not count hardlinks in NTFS (nlink property)
- if you mount a second file system in an NTFS folder, stat does not return the other file system's root stats, but the mount point's stats.
|
Sun 12 Apr 2015 01:51:05 PM UTC, comment #4:
Yes, you can create symlinks and hardlinks in the NTFS file system using the “mklink” command. However, it requires special permission to do so.
I have verified, that stat does not follow symlinks on Windows, neither for directories nor for files.
|
Sun 12 Apr 2015 01:38:25 PM UTC, comment #3:
Windows has symlinks?!? :)
Seriously I did not know that.
See "help stat", especially the comparison between stat and lstat. The stat function is supposed to follow the symlink, report the details of the target of the symlink, not the symlink itself. The lstat function is supposed to return details for the symlink. It sounds like stat is not following the symlink on your setup.
|
Sun 12 Apr 2015 01:19:15 PM UTC, comment #2:
Your instructions help a lot to clarify this. The cause seems to be the use of symlinks in my file system.
In my case “pwd” refers to a directory, which is a symlink. The symlink target's mtime changes when I add a new file. stat (pwd).mtime is the modification time of the symlink itself, which does NOT change.
So, the mtime update works as expected, but some internal process fails to refresh its file cache, because it does not resolve symlinks when checking for mtime?!?
|
Sun 12 Apr 2015 01:00:17 PM UTC, comment #1:
Does this have to do with directory timestamps on your filesystem?
There was a similar bug about m-files in the root directory of a network drive or a thumbdrive or something like that.
Octave expects the modification timestamp of the directory containing the newly created m-file to be updated. Can you see what's going on with this example?
|
Sun 12 Apr 2015 08:33:17 AM UTC, original submission:
When I create new files with the integrated editor, I cannot run them by their filename. I have to prefix a path.
However, when I restart GNU Octave, any files that existed before the start of GNU Octave can be found.
This also lets some Octave Forge package tests fail, which create and call temporary m-files.
|