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

[John W. Eaton]

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

I wrote: "We can only start to debug this problem if we know what that
difference is." but I decided to look for differences in what happens for
stat(name) and stat(fid) on Windows systems anyway.

In the definition of the stat function in libinterp/corefcn/syscalls.cc, I
see


  if (args(0).is_scalar_type ())
    {
      stream_list& streams = interp.get_stream_list ();

      int fid = streams.get_file_number (args(0));

      sys::file_fstat fs (fid);

      retval = mk_stat_result (fs);
    }
  else
    {
      std::string fname = args(0).xstring_value ("stat: NAME must be a
string");

      sys::file_stat fs (fname);

      retval = mk_stat_result (fs);
    }


In liboctave/system/file-stat.cc, I see that fstat calls octave_fstat_wrapper
and stat calls either octave_stat_wrapper or octave_lstat_wrapper.  Those
functions are defined in liboctave/wrappers/stat-wrappers.c.

For octave_fstat_wrapper, we call the gnulib replacement for fstat.  On
Windows systems, that apparently calls the function _gl_fstat_by_handle that
is defined in gnulib/lib/stat-w32.c and that function calls one or more
Windows functions (check out the sources for that function for the details,
it's complicated as it is trying to cope with changes in the Windows API and
provide as much info as it can to fill the stat structure).

For the octave_stat_wrapper and octave_lstat_wrapper functions, I see


#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


and


#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


so for those functions, we are skipping the gnulib wrapper completely on
Windows systems and assuming that the Windows _wstati64 function does the
right thing.  If I understand this bug report correctly, _wstati64 is *not*
doing the right thing, but the gnulib wrapper for fstat is?  Or do I have that
backward?


    _______________________________________________________

Reply to this item at:

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

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