Re: init_buffer PWD fix

[Eli Zaretskii <eliz@is.elta.co.il>]

On Mon, 22 Apr 2002, Paul Eggert wrote:

> > > Fcopy_file uses the conditional
> > > `#if !defined (DOS_NT) || __DJGPP__ > 1' before inspecting st_ino;
> > > would that be appropriate here too?
> > 
> > DJGPP emulates the inodes well enough for the code to work, but the 
> > Windows port is not compiled with DJGPP.
> 
> 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, so on Windows Emacs simply doesn't support the feature 
whereby it tells you that the source and destinations are the same file.  
But since there are no symlinks on Windows, the only way this can happen 
is if the user transmogrifies the file name in some way, which is 
something less probable than collisions involving symlinks.

Or did you mean something else?

> Anyway, rather than get sucked into st_ino portability hell, how about
> checking st_mtime as well?  That is, after doing this:
> 
>       && stat (pwd, &pwdstat) == 0
>       && stat (".", &dotstat) == 0
>       && dotstat.st_ino == pwdstat.st_ino
>       && dotstat.st_dev == pwdstat.st_dev
> 
> init_buffer can do this:
> 
>       && 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 (and cannot be changed with any system call, only by 
accessing the disk at the sector level).

> > Personally, I think the code in buffer.c could compare normalized file 
> > names as either an alternative or a complementary to the inode method.
> 
> What's a "normalized file name"?

For DOS/Windows systems, it's roughly a full absolute file name, in some 
standard letter-case (either all uppercase or all lowercase), and with 
all slashes converted to a single style (either all forward slashes or 
all backslashes).

> Can it be computed as quickly as an inode number can?

Every reliable method of inode simulation that I know of begins by 
computing a normalized file name (since you need to assign the same 
inode number when you see the same file).  So it's as fast as a 
simulated inode or faster.

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.