Subject: find-file-existing-other-name / file-alias-p (again!)

From: "Kim F. Storm" <[email-masked]>
Date: Mon, 16 Sep 1996 10:24:42 +0200 (MET DST)

I am thinking of changing the default value of
   find-file-existing-other-name to t.

   Would you pretesters please try setting this to t
   in your .emacs files, and see if you notice any
   unpleasant consequences of that setting?

I have been using this setting on Windows95 for months now without
problems -- except that it doesn't work reliably (as I have told you
before).

On Windows95, NT (and DOS using the Windows95 VFAT file system), there
is currently no way to correlate a file's long-name and its short-name
counterpart.  In the VFAT file system, a file with a long-name which
does not follow the traditional 8.3 filename format is also given an
8.3 short-name for the benefit of older (DOS) applications which do
not understand long filenames.  For example, a file whose long-name is
VERYLONGNAME.XYZ will typically be assigned a short-name VERYLO~1.XYZ

I have previously proposed to make a file-alias-p function which could
return one and only one "truename" of a file with more than one
internal name (or nil if the given name is the truename).

But you rejected the idea because you didn't want a function with a
generic name such as file-alias-p, nor did you want to use it in
files.el. I don't quite understand why you were opposed to include
this function which I think I have named very appropriately (just link
file-symlink-p is named appropriately for the system which has
symlinks and is a no-op on file systems without symlinks).

On Windows95 and DOS, file-alias-p would be able to return the
long-name for a given short-name, and on file systems where the case
in filenames is ignored (also on Windows95), it could downcase (or
up-case depending on tradition) the filename to ensure a consistent
naming of the file.

This means that file-alias-p would have a function on at least
Windows95, NT and MS-DOS, and may find its uses on other systems in
the future (and of the past).

Of course, on file systems which has a reliable file-number, this
really doesn't really matter (since you only need to compare the
buffer-file-numbers), but when buffer-file-numbers-unique indicates
that file numbers are not unique, the buffer-file-truename should give
a reliable identification of a file!

I would be happy to send you my pathces for the file-alias-p function.
Given your previous comments, I would change these so that there is
only very simple file-alias-p stub-function in fileio.c which just
calls the appropriate windows32_file_alias_p or msdos_file_alias_p
function defined in the appropriate nt.c or msdos.c files.
And there would just be two extra lines in files.el to support this.

--
Kim F. Storm, Olicom A/S <[email-masked]>

---

From: Eli Zaretskii <[email-masked]>
Date: Mon, 16 Sep 1996 12:19:14 +0200 (IST)

On Mon, 16 Sep 1996, Kim F. Storm wrote:

> files.el.

Since I never looked into this problem, I will probably risk sticking my
nose into an issue which obviously at least Kim has thought a lot about (I
can tell, because I hardly unbderstand more than half of what he wrote). 
However, at least the next release of DJGPP *does* have a way to associate
a long filename and its short alias.  Also, the next release offers much
better support of LFN platforms in libc.a, and AFAIK, the inode numbers we
get from `stat' and `fstat' are consistent no matter what do you call the
file.  So I would warn against deciding one way or another on this issue
before at least testing it with the new DJGPP library.  DJGPP v2.1 is now
in alpha testing, and will probably go into beta sometimes this week. 

I'd appreciate if somebody (Kim?) could tell me a bit more about the
problem, the proposed solution(s) and difficulties, if any, with the
proposed solutions (just assume I know nothing about it), so I could at
least provide a meaningful feedback on the implications of changing Emacs
behavior, and maybe even help testing this on DOS/Wndows 95.  If there 
are any NT-specific points here, maybe Geoff and Andrew could tell me 
about them too?  Thanks.

---

From: Richard Stallman <[email-masked]>
Date: Mon, 16 Sep 1996 05:46:00 -0400

Would it be appropriate for file-truename to do these things
on systems where they are called for?

---

From: "Kim F. Storm" <[email-masked]>
Date: Mon, 16 Sep 1996 15:03:16 +0200 (MET DST)

Date: Mon, 16 Sep 1996 05:46:00 -0400
   From: Richard Stallman <[email-masked]>
   Cc: [email-masked], [email-masked], [email-masked]

Yes, indeed!  I wasn't specific about this in my description, but is
actually file-truename which has to call file-alias-p to find the
file's truename (similarly to the way it calls file-symlink-p, but
without chasing any links).

---

From: "Kim F. Storm" <[email-masked]>
Date: Mon, 16 Sep 1996 15:27:57 +0200 (MET DST)

Date: Mon, 16 Sep 1996 12:19:14 +0200 (IST)
   From: Eli Zaretskii <[email-masked]>

Sorry about that!

The background is that in the Windows32 API there is no way (as far as
I know) to get a reliable buffer-file-number (e.g. device+inode
number) for a file.  The problem is that the "inode number" is only
valid as long as the file is open, so after you close the file and
open another file, the second file may (easily) have the same "inode
number" as the first file.

Andrew Innes has made (sort of) a fix which creates an inode number
based on a hash-value on the file's pathname, but that isn't quite reliable
either (at least not in my experience).

It sent RMS a patch for find-buffer-visiting which could tell it (via
the new buffer-file-numbers-unique variable) to disregard the
file-numbers and just base its assumptions on the buffer-file-truename.

However, since a file may in fact have two different names using the
VFAT file system, opening a file with its short-name as well as its
long-name will bring up the file in two different buffers.

Normally, this isn't a big problem, but if the filename is obtained
via a DOS shell (which is the case when the gnuclient sends a file
name to emacs) the short-name form is delivered rather than the
long-name form.

Another situation where this happens to me is when I use some older DOS
tools to get a list of file names to process in emacs; then the
short-names of the files will be used and it then fails to associate
the files on the list with currently open files...

Since the DOS port of emacs obviously has reliable inode numbers there
isn't a great need for the file-alias-p method to obtain the truename.

Still, the file-alias-p functionality of returning the long-name
corresponsing to a given short-name would have its uses on MS-DOS as
well, e.g. to name the buffer according to the long-name of a file
even when opening the short-name version of the file by setting
find-file-visit-truename.

Well, I don't see any real dangers doing what I propose.  It is simply
a way to ensure that there is one and only one truename for any given
file (whenever that matters).  I had implemented this in 19.31 for
Windows95 without observing any ill effects, but I have not moved my
changes to 19.34 since I haven't had time to do so.

---

From: Eli Zaretskii <[email-masked]>
Date: Mon, 16 Sep 1996 18:00:57 +0200 (IST)

> either (at least not in my experience).

That's exactly how `stat' in DJGPP works on Windows 95 (on MSDOS, it gets
the the real inode number--the starting cluster of the file on disk, but
on Windows 95 it hashes the name).  It is reliable enough on MSDOS, so I
suggest that `stat' replacement on src/nt.c be augmented to be reliable on
NT.  Since I wrote most of the code for `stat' in DJGPP library, I can
help NT Andrew and/or Geoff make it work at least this reliable on NT. 

IMHO, if a problem is specific to some platform, it should be solved on 
files specific to that platform, if that's possible, without polluting 
the mainline of Emacs code even with a single line.

> long-name will bring up the file in two different buffers.

That is solved in DJGPP and can be solved the same way on NT.  I just 
tested this again with DJGPP Emacs on Windows 95, to be sure:

	C-x C-f AVeryLongFileName RET
	C-x C-f AVERYL~1 RET

and promptly got the familiar ``these files are the same'' message.  The
secret to this is that before hashing the name, `stat' in DJGPP calls the
GetLongPathName function of Windows 95 (I'm not sure if that is how it is
called in MSVC, but I'm pretty sure there should be such a call), which
always returns a canonicalized long full pathname, even if you feed it
with a short 8+3 alias. 

Should the need arise, you can also get the short 8+3 name given a long 
one.  In DJGPP there is no need for this currently, but several library 
functions make such calls internally, to transparently support both LFN 
and non-LFN platforms.

> find-file-visit-truename.

If at all required (once `stat' is fixed), I think the best way to do that
is to define a handler for the file-truename function which will call the
above Windows 95 function.  The current code that computes the true name
assumes the only reason for alias names is the symlinks, so it is
irrelevant for the case in point. 

> changes to 19.34 since I haven't had time to do so.

If you have time to spare, I suggest you get Emacs 19.34 for MSDOS (I can 
tell you where to get the binary compiled with pre-release of DJGPP 
v2.01) and try it on Windows 95 to see if it works reliably in the above 
context.  If it does, I think augmenting the `stat' replacement on 
stc/nt.c is a better solution.