bugGNU Octave - Bugs: bug #53917, Incorrect warning: time stamp for...

 
 

bug #53917: Incorrect warning: time stamp for 'filename' is in the future

Submitter:  Ian McCallion <ianmcc>
Submitted:  Tue 15 May 2018 08:18:15 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.4.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 25 May 2018 05:07:53 PM UTC, comment #8: 

Ok, if this ever returns we have a good start at debugging it here.

Mike Miller <mtmiller>
Group Member
Mon 21 May 2018 06:45:18 PM UTC, comment #7: 

Well the problem STILL does not show with my original script.

I can only assume it was a glitch that persisted for a day or so and was cured when I rebooted the system.

If there is an actual Octave bug causing the problem it is very obscure and probably of no significance.

Ian McCallion <ianmcc>
Mon 21 May 2018 05:50:46 PM UTC, comment #6: 

Duhhh yes! I had tried with a script, but not with an actual function file.

Now to remember what I was going to try out!

Ian McCallion <ianmcc>
Mon 21 May 2018 05:45:21 PM UTC, comment #5: 

Ian - if you remember, you said that dummy.m must be a valid Octave function file. In the output you show here it looks like dummy.m is an empty file. Is that the reason you are not getting the warning now?

Mike Miller <mtmiller>
Group Member
Mon 21 May 2018 05:30:41 PM UTC, comment #4: 

I have tried to do some more work on this, but when rerunning my original scripts the error was not occurring. Even more peculiarly, I am now unable to provoke the warning message even when the script file timestamp is a year in the future as shown in this console log:


GNU Octave, version 4.4.0
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

>> system('touch dummy.m -t 201906011205') % make sure timestamp is well into the future
ans = 0
>> system 'dir dummy.m'
 Volume in drive C is OS
 Volume Serial Number is 36F0-859C

 Directory of C:\Users\Ian

01/06/2019  12:05                 0 dummy.m
               1 File(s)              0 bytes
               0 Dir(s)  379,096,993,792 bytes free
ans = 0
>> warning on
>> dummy
>>

Hence I am at this point unable to do more experiments to further this bug discussion.

I am unaware that I have made any changes to Octave between the time of my original post and now. I get exactly the same behaviour on 4.2.2

Ian McCallion <ianmcc>
Fri 18 May 2018 05:29:11 PM UTC, comment #3: 

What I can interpret from this so far is that the Windows function call GetFileInformationByHandle is returning a BY_HANDLE_FILE_INFORMATION structure that contains a ftLastWriteTime time stamp that is in the future.

According to what I have read, this time stamp should be in UTC regardless of the time zone setting if the file system is NTFS. But you are seeing a time stamp that is in the future.

I can't explain or assume any further than that, maybe someone will have to write an oct file that uses the Windows API functions directly to see what the time stamp is after the 'touch' command completes. And whether the time stamp continues to change as the TZ environment variable is changed.

Mike Miller <mtmiller>
Group Member
Fri 18 May 2018 12:54:20 PM UTC, comment #2: 

I can confirm that adding those two lines the mtime field is larger, by the expected amount for the timezone shift.

Ian McCallion <ianmcc>
Tue 15 May 2018 10:27:35 PM UTC, comment #1: 

Can you add the following


tnow = time ()
out = stat ('dummy.m')


after the pause, and show the output?

If I'm following the code correctly, the time stamp shown in the 'mtime' field of 'out' should be larger than the value of 'tnow' for this warning to be printed.

Mike Miller <mtmiller>
Group Member
Tue 15 May 2018 08:18:15 PM UTC, original submission:  

The script below shows an unwanted interaction between using TZ for the purposes of the application and Octave's inappropriate dependency on the current value of of TZ in monitoring the Octave path for changed files. (Caveat. I'm on windows)
Before launching this script, create a valid do-nothing function called dummy.m. An empty file does not show the problem

system('touch dummy.m') % make sure timestamp is NOW
setenv('TZ', 'UTC0'); % !!!!! USE A TIMEZONE THAT IS WESTERLY FOR YOUR LOCATION !!!!
mktime(localtime(1)); % This is necessary only in Octave for Windows to bypass a bug in the posix layer which will be reported separately
pause (2); % Does not always happen without the pause
% the next command should report that the file has a timestamp in the future
dummy
setenv('TZ', '')
mktime(localtime(1));


I am using Windows 10. The file is on a hard disk formatted NTFS. The touch command sets the filetime correctly to the current time yet the output of the script is:

>> filechangedbug
ans = 0
warning: time stamp for 'C:\Users\Ian\documents\backed\HawkEarGit\dummy.m' is in the future
warning: called from
    filechangedbug at line 8 column 1
dummy


Ian McCallion <ianmcc>

 

(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 mtmiller (Posted a comment)
  • -email is unavailable- added by ianmcc (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-25 mtmiller StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2018-05-15 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code