bugGNU Octave - Bugs: bug #44814, incorrect behavior from stat() for...


bug #44814: incorrect behavior from stat() for some symlinks on Windows NTFS file systems

Submitted by:  Oliver Heimlich <oheim>
Submitted on:  Sun 12 Apr 2015 08:33:17 AM UTC  
Category:  Interpreter Severity:  2 - Minor
Priority:  1 - Later Item Group:  Incorrect Result
Status:  Postponed Assigned to:  None
Originator Name:  Oliver Heimlich Open/Closed:  Open
Release:  4.0.0 Operating 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)

Tue 02 Jun 2015 04:47:31 PM UTC, comment #9:

Retagging release from 4.0.0-rc3 to 4.0.0.

John W. Eaton <jwe>
Project Administrator
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.

Rik <rik5>
Project Administrator
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:
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)

Philip Nienhuis <philipnienhuis>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
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.

Oliver Heimlich <oheim>
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.

Oliver Heimlich <oheim>
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.

Mike Miller <mtmiller>
Project Administrator
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?!?

Oliver Heimlich <oheim>
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?

Mike Miller <mtmiller>
Project Administrator
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.

Oliver Heimlich <oheim>


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

Attach Files:

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 jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by oheim (Submitted the item)

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

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-21 mtmiller Severity3 - Normal => 2 - Minor
        Priority3 - Low => 1 - Later
        StatusNeed Info => Postponed
    2015-06-02 jwe Release4.0.0-rc3 => 4.0.0
    2015-04-17 rik5 Priority5 - Normal => 3 - Low
        Summarywhich and run fail on windows for new files => incorrect behavior from stat() for some symlinks on Windows NTFS file systems
    2015-04-12 mtmiller StatusNone => Need Info

    Back to the top

    Powered by Savane 3.4