Re: init_buffer PWD fix

[Paul Eggert]

> From: Eli Zaretskii <address@hidden>
> Date: Mon, 22 Apr 2002 14:14:48 +0300 (IDT)
>
> >       && dotstat.st_mtime == pwdstat.st_mtime
> > 
> > This won't hurt much on non-broken systems, and it should fix the vast
> > majority of the problem on systems where st_ino is broken.
> 
> That would be unreliable, I think: on some Windows filesystems, the time 
> stamp of a directory is determined when the directory is created, and 
> then never changes

I don't see why this would cause a problem.  That code-change would
make st_mtime be a double-check on st_ino.  I think you're suggesting
that st_mtime might be a somewhat random number that never changes,
but that's great: that's just what we want here.

> Perhaps it's high time we added a file-name comparison primitive to 
> Emacs.  There are few other places where it could be useful.  On Posix 
> platforms it could compare inodes, while other platforms will do their 
> own magic.

I suggest looking at the following macros from GNU diffutils/src/system.h:

  same_file
  same_file_attributes

especially the commentary.

Unfortunately, st_ino is not reliable even on many platforms that
nearly conform to POSIX, and this includes GNU/Linux.  The best
workaround for this problem depends on the application.  For some
applications, this is better:

  if (0 < same_file (&stat_buf[0], &stat_buf[1])
      && same_file_attributes (&stat_buf[0], &stat_buf[1]))
    assume_files_are_same ();
  else
    assume_files_are_different ();

and for other applications, this is better:

  if (0 < same_file (&stat_buf[0], &stat_buf[1]))
    assume_files_are_same ();
  else
    assume_files_are_different ();

and there are other possibilities, too, alas.


> > Hmm, I guess nobody told the author of Fcopy_file....  Perhaps there's
> > an opportunity for code consolidation/cleanup there.
> 
> Not sure what you mean here: the inode comparison is ifdef'ed away for 
> the Windows port,

The inode comparison is done if (! defined WINDOWSNT && (!defined
(DOS_NT) || __DJGPP__ > 1)).  Sorry, I don't know the ins and outs of
the Windows ports, but I assumed that there could be a non-WINDOWSNT
port out there.  Maybe I'm confusing Windows and DOS, though.