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

 
 

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

Submitter:  Oliver Heimlich <oheim>
Submitted:  Sun 12 Apr 2015 08:33:17 AM UTC
   
 
Category:  Interpreter Severity:  2 - Minor
Priority:  1 - Later Item Group:  Incorrect Result
Status:  Need Info Assigned to:  None
Originator Name:  Oliver Heimlich Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 10 Mar 2019 06:31:04 PM UTC, comment #11: 

No response, closing report.

Rik <rik5>
Group administrator
Mon 04 Mar 2019 03:32:14 AM UTC, comment #10: 

Is this bug still present in Octave 5.1? In this latest release, the Windows native function '_wstati64' is used instead of gnulib's implementation of the stat function.

Mike Miller <mtmiller>
Group Member
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>
Group 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>
Group 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:
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)

Philip Nienhuis <philipnienhuis>
Group 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>
Group Member
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>
Group Member
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?


>> format long
>> stat (pwd ()).mtime
## create new m-file
## verify new m-file exists and which fails
>> stat (pwd ()).mtime
## is there a way to force mtime update in windows? touch cmd?


Mike Miller <mtmiller>
Group Member
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.


>> dir hello.m
hello.m
>> which hello.m
>> run hello.m
no such file, ''
error: called from 'run' in file S:\Programme\Octave-4.0.0-rc3\share\octave\4.0.0-rc3\m\miscellaneous\run.m near line 84, column 5
>> hello
error: 'hello' undefined near line 1 column 1
>> run ./hello.m
Hello World


However, when I restart GNU Octave, any files that existed before the start of GNU Octave can be found.


>> dir hello.m
hello.m
>> which hello.m
'hello.m' is the file C:\Users\Oliver\hello.m
>> run hello.m
Hello World
>> hello
Hello World


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:
   
   
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 jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by oheim (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.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-10 rik5 Open/ClosedOpen Closed
    2019-03-04 mtmiller StatusPostponed Need Info
    2019-03-04 mtmiller Carbon-CopyRemoved 80942 -
    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.13-4448.
    Corresponding source code