bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13149: 24.3.50; Emacs thinks file was changed outside Emacs, but it


From: Paul Eggert
Subject: bug#13149: 24.3.50; Emacs thinks file was changed outside Emacs, but it was not
Date: Thu, 17 Jan 2013 13:33:06 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 01/17/13 02:32, Dmitry Gutov wrote:
> dired.c:958: stat_mtime=1358412092.606214085
> modify again
> fileio.c:5414: stat_mtime=1358412092.606214000

The first time stamp comes from lstat, the second
from stat.  If the file is actually on an NTFS file
system from the underlying host, the first time stamp
cannot possibly be right, since these file systems
have a time stamp resolution of 100 nanoseconds.
The second time stamp would be the correct one.

So it does seem to be a file system bug.  Is this something
that you can reproduce with a little C program, that
creates a file, and invoke lstat and stat on it?
What happens when you run the following program
in your file system?  It should output time stamps
that are identical.  You may need to substitute
something else (like sleep (10)) for "sync ()"
to trigger the bug.

#include <fcntl.h>
#include <sys/stat.h>
#include <stdio.h>
#include <unistd.h>

int
main (void)
{
  char const *file = "foo";
  struct stat lst, st;
  int fd;
  unlink (file);
  fd = open (file, O_CREAT | O_WRONLY, -1);
  if (fd < 0)
    return perror ("open"), 1;
  if (lstat (file, &lst) != 0)
    return perror ("lstat"), 1;
  sync ();
  if (stat (file, &st) != 0)
    return perror ("stat"), 1;
  printf ("%ld.%09ld\n", (long) lst.st_mtim.tv_sec, lst.st_mtim.tv_nsec);
  printf ("%ld.%09ld\n", (long) st.st_mtim.tv_sec, st.st_mtim.tv_nsec);
  return 0;
}






reply via email to

[Prev in Thread] Current Thread [Next in Thread]