[Octave-bug-tracker] [bug #64933] Stat sometimes produces wrong timestamp

[John W. Eaton]

Follow-up Comment #15, bug #64933 (project octave):

The important thing here is that for a single file (however/whenever it was
created), the {a,c,m}time elements of the struct returned from the two calls


stat ("filename")
stat (fopen ("filename"))


are different and they should not be.  There should be only one number of
seconds since the epoch that this file was created, regardless of time zone or
DST, correct?

And if I understand correctly, the "stat (filename)" call is the one that gets
it wrong and that is the one that ultimately calls _wstati64.

What happens if we make the following change?  Does the gnulib replacement for
stat return the correct result?


diff --git a/liboctave/wrappers/stat-wrappers.c
b/liboctave/wrappers/stat-wrapp>
--- a/liboctave/wrappers/stat-wrappers.c
+++ b/liboctave/wrappers/stat-wrappers.c
@@ -117,13 +117,7 @@ octave_stat_wrapper (const char *fname, 
 {
   struct stat buf;
 
-#if defined (OCTAVE_USE_WINDOWS_API)
-  wchar_t *wfname = u8_to_wchar (fname);
-  int status = _wstati64 (wfname, &buf);
-  free ((void *) wfname);
-#else
   int status = stat (fname, &buf);
-#endif
 
   assign_stat_fields (&buf, mode, ino, dev, nlink, uid, gid, size,
                       atime, mtime, ctime, rdev, blksize, blocks);
@@ -140,14 +134,7 @@ octave_lstat_wrapper (const char *lname,
 {
   struct stat buf;
 
-#if defined (OCTAVE_USE_WINDOWS_API)
-  // Windows doesn't have an lstat. Use stat instead
-  wchar_t *wlname = u8_to_wchar (lname);
-  int status = _wstati64 (wlname, &buf);
-  free ((void *) wlname);
-#else
   int status = lstat (lname, &buf);
-#endif
 
   assign_stat_fields (&buf, mode, ino, dev, nlink, uid, gid, size,
                       atime, mtime, ctime, rdev, blksize, blocks);


I understand that the calls to _wstati64 were made in
http://hg.savannah.gnu.org/hgweb/octave/rev/7fb40efda31f to support wide
characters in filenames on Windows to solve bug #49118.  How can we solve both
problems?  It's surprising to me that _wstati64 has this behavior.  Is there
something I don't understand about why it works this way?

Oh, so now I see this thread that provides some background about why gnulib
has a replacement for stat: 
https://lists.gnu.org/r/bug-gnulib/2017-04/msg00126.html and also  has some
discussion about the crazy DST behavior.

I also found this post about what appears to be the same issue:
https://www.nu42.com/2015/03/stat-vs-fstat-msvcrt-windows.html


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64933>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/