From owner-ntemacs-users@june Fri Sep 6 10:50:15 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Fri" " 6" "September" "1996" "13:00:56" "-0400" "Dave Strauss" "dstrauss@systemsoft.com" nil "67" "Case sensitivity in etags" "^From:" nil nil "9" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id KAA26503 for ; Fri, 6 Sep 1996 10:50:15 -0700 Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id KAA25193 for ; Fri, 6 Sep 1996 10:50:12 -0700 Received: from ssftsun.systemsoft.com (ssftsun.leftbank.com [199.94.246.68]) by june.cs.washington.edu (8.7.5/7.2ju) with ESMTP id KAA20320 for ; Fri, 6 Sep 1996 10:06:11 -0700 Received: from dstrauss ([199.94.246.187]) by ssftsun.systemsoft.com (8.7.5/8.7.3/LeftBank-SystemSoft-1.0) with SMTP id NAA09972 for ; Fri, 6 Sep 1996 13:00:56 -0400 (EDT) Message-Id: <199609061700.NAA09972@ssftsun.systemsoft.com> X-Sender: dstrauss@ssftsun.systemsoft.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: Dave Strauss To: ntemacs-users@cs.washington.edu Subject: Case sensitivity in etags Date: Fri, 6 Sep 1996 13:00:56 -0400 (EDT) I'm having a problem with setting up tags files for use on multiple-level sources trees. For reference, I'm currently using emacs 19.34 on NT 4.00 Beta 2 (build 1314), but the problem (if that's what it is) has existed at least at least in some form as far back as emacs 19.30. I recently upgraded from emacs 19.31. Under Unix, I would do something like this, if I knew the depth of the source tree: etags *.[ch] */*.[ch] */*/*.[ch] ... Or I might use "find" and pipe the results into etags. Under NT, I've been doing the following from a DOS (cmd.exe) box: dir /s /b *.c *.h *.cpp | etags - This gives me file names in the tags file like the following: C:/dir1/Files/File1.c The problem occurs because NT (and win95?) preserve case in filenames; most utilities ignore filename case, but emacs doesn't. So, for example, I might open the file c:/foobar/foobar/foobar.txt by typing in the file name, but if I use filename completion I might end up opening c:/FooBar/FOOBAR/fooBar.txt. Emacs sees these as different files, even though they are the same. In emacs 19.31, the drive letters were upper-cased; I would get (via filename completion) names like C:/file1 and C:/File2. Because of this, if I was careful in setting up my current directory in DOS, the file names in the tags file would match the file names I would get via filename completion. But in emacs 19.34, the drive letters are now lower-cased. So now there is no way I can get the file names in the tags file to match the filename-completion names. As a result, I sometimes have two, and even three or four, copies of the same file open at the same time. It gets very confusing trying to remember which copy I'm editing! I would like to be able to do one of the following (in order of preference): 1) Convince emacs to ignore case (like other NT/Win95 utilities) when opening files. 2) Make emacs force driver letters to be upper-cased, as before. [Less desirable that (1), but at least I had learned to live with it!]. 3) Find another way of creating tags files for multiple-level source trees so the file names match what emacs expects. But note that I don't always know the depth of the source trees! 4) Other ??? Does anyone know how to do any of these things? Preferably through modifications of the elisp code? Thanks. --------------------------------------------------------------------------- "The best ideas do not | David Strauss dstrauss@systemsoft.com necessarily come from | Principal Engineer http://www.systemsoft.com the loudest voices" | SystemSoft Corp. Phone: 508-647-2873 | 2 Vision Drive Fax: 508-651-8188 | Natick, MA 01760-2059 --------------------------------------------------------------------------- From owner-ntemacs-users@june Fri Sep 6 12:42:24 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Fri" " 6" "September" "1996" "11:52:12" "-0700" "Robert Brodersen" "rbrodersen@siebel.com" nil "18" "RE: Case sensitivity in etags" "^From:" nil nil "9" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id MAA08460 for ; Fri, 6 Sep 1996 12:42:24 -0700 Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id MAA15502 for ; Fri, 6 Sep 1996 12:42:21 -0700 Received: from mail2.exodus.net (mail2.exodus.net [206.79.240.110]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id LAA03757 for ; Fri, 6 Sep 1996 11:52:17 -0700 Received: from zeus.Siebel.com (zeus.siebel.com [206.79.142.20]) by mail2.exodus.net (8.6.12/8.6.9) with SMTP id LAA20366 for ; Fri, 6 Sep 1996 11:52:15 -0700 Received: by zeus.Siebel.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9BE9.D83C3410@zeus.Siebel.com>; Fri, 6 Sep 1996 11:52:14 -0700 Message-ID: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Robert Brodersen To: "'ntemacs-users@cs.washington.edu'" , "'Dave Strauss'" Subject: RE: Case sensitivity in etags Date: Fri, 6 Sep 1996 11:52:12 -0700 >> Dave Strauss writes:: >But in emacs 19.34, the drive letters are now lower-cased. So now there >is no way I can get the file names in the tags file to match the >filename-completion names. As a result, I sometimes have two, and >even three or four, copies of the same file open at the same time. It >gets very confusing trying to remember which copy I'm editing! I used to have filename case problems all the time, and I solved it with this beauty: Add the following to your .emacs file ; Don't visit two buffers of the same file (solves some filename case problems) >(setq find-file-existing-other-name t) Bob Brodersen -- rbrodersen@siebel.com From owner-ntemacs-users@june Fri Sep 6 16:34:31 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Fri" " 6" "September" "1996" "15:44:22" "-0700" "Robert Brodersen" "rbrodersen@siebel.com" nil "42" "find-file-existing-other-name doesn't work in 19.33 (was Case sensitivity in etags)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id QAA04768 for ; Fri, 6 Sep 1996 16:34:31 -0700 Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id QAA15578 for ; Fri, 6 Sep 1996 16:34:27 -0700 Received: from mail2.exodus.net (mail2.exodus.net [206.79.240.110]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id PAA29265 for ; Fri, 6 Sep 1996 15:44:26 -0700 Received: from zeus.Siebel.com (zeus.siebel.com [206.79.142.20]) by mail2.exodus.net (8.6.12/8.6.9) with SMTP id PAA24471 for ; Fri, 6 Sep 1996 15:44:23 -0700 Received: by zeus.Siebel.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9C0A.47175CA0@zeus.Siebel.com>; Fri, 6 Sep 1996 15:44:23 -0700 Message-ID: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Robert Brodersen To: "'ntemacs-users@cs.washington.edu'" , "'Dave Strauss'" Subject: find-file-existing-other-name doesn't work in 19.33 (was Case sensitivity in etags) Date: Fri, 6 Sep 1996 15:44:22 -0700 I can confirm that this used to work in 19.31, but it doesn't work in 19.33. In 19.31 I get the following message: C:/UTLDATA.C and C:/utldata.c are the same file When I try to open utldata.c again with different filename case, and the existing buffer is selected. I noticed that files.el changed a bit from 19.31 to 19.33, but when I tried to run the .31 version in .33, the bug still seems to be there. I would really appreciate a fix to this great feature!!! >---------- >From: Dave Strauss[SMTP:dstrauss@systemsoft.com] >Sent: Friday, September 06, 1996 3:03 PM >To: Robert Brodersen; ntemacs-users@cs.washington.edu >Subject: RE: Case sensitivity in etags > >At 11:52 AM 9/6/96 -0700, Robert Brodersen wrote: > +---- > | >> Dave Strauss writes:: > | > | >But in emacs 19.34, the drive letters are now lower-cased. So now there > | >is no way I can get the file names in the tags file to match the > | >filename-completion names. As a result, I sometimes have two, and > | >even three or four, copies of the same file open at the same time. It > | >gets very confusing trying to remember which copy I'm editing! > | > | I used to have filename case problems all the time, and I solved it with > | this beauty: > | > | ; Don't visit two buffers of the same file (solves some filename case > | problems) > | (setq find-file-existing-other-name t) > | > | Bob Brodersen -- rbrodersen@siebel.com > +---- > >I tried this; it doesn't seem to make any difference (at least with >19.34). I can still open a file into two buffers; for example >Foo.txt and foo.Txt. > >-- Dave Strauss (dstrauss@systemsoft.com -or- dstrauss@gis.net) > From owner-ntemacs-users@june Fri Sep 6 19:47:09 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Fri" " 6" "September" "1996" "17:49:07" "-0700" "Richard Y. Kim" "ryk@ap.com" nil "76" "find-file-existing-other-name doesn't work in 19.33 (was Case sensitivity in etags)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id TAA20825 for ; Fri, 6 Sep 1996 19:47:09 -0700 Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id TAA15367 for ; Fri, 6 Sep 1996 19:47:02 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by june.cs.washington.edu (8.7.5/7.2ju) with ESMTP id SAA17874 for ; Fri, 6 Sep 1996 18:56:25 -0700 Received: from uucp5.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp5.UU.NET [192.48.96.36]) id QQbgbn15395; Fri, 6 Sep 1996 21:56:24 -0400 (EDT) Received: from audiotst.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 6 Sep 1996 21:56:24 -0400 Received: (from ryk@localhost) by audiotst.ap.com (8.6.12/8.6.12) id RAA15449; Fri, 6 Sep 1996 17:49:07 -0700 Message-Id: <199609070049.RAA15449@audiotst.ap.com> Reply-To: ryk@ap.com In-Reply-To: References: From: "Richard Y. Kim" To: Robert Brodersen CC: ryk@audiotst.ap.com, ntemacs-users@cs.washington.edu Subject: find-file-existing-other-name doesn't work in 19.33 (was Case sensitivity in etags) Date: Fri, 6 Sep 1996 17:49:07 -0700 I posted this many months ago before 19.31 was released. I have made some changes to make it work with 19.31 and up. I don't know whether this is obsoleted by find-file-existing-other-name or not, but this has served me well for several months. ;;; stdname.el --- use standard file names to prevent duplicate buffers ;;; Copyright (c) 1996 Richard Y. Kim ;;; Author: Richard Y. Kim, ;;; Maintainer: Richard Y. Kim, ;;; Created: Sat Feb 17 15:40:42 1996 ;;; Version: $Id: stdname.el,v 1.6 1996/08/02 21:59:50 ryk Exp ryk $ ;;; Keywords: ;;; ;;; Description: ;;; This solves (for many situations but not all) the annoying problem ;;; where multiple buffers are created for the same file under Windows ;;; 95 due to case insensitivity of the Windows file system, e.g., ;;; ;;; C:\home\somefile ;;; c:\home\SOMEFILE ;;; c:\HOME/somefile ;;; ;;; The following code prevents the creation of multiple buffers. ;;; ;;; Installation: ;;; Simply load this file in your .emacs, _emacs, emacs.ini, or whatever, ;;; e.g., (load-library "stdname"). ;;; ;;; Commentary: ;;; This was tested using pre-built Ntemacs 19.31 under Windows 95. ;;; The URL for ntemacs is something like ;;; ;;; ftp://ftp.cs.washington.edu/pub/ntemacs. ;;; ;;; Bugs: ;;; I think stdname.el should be disabled for NT, but I don't know how ;;; to distinguish win95 verses nt in emacs-lisp. ;;; On my ntemacs-19.33 running on Windows 95, (getenv "winbasedir") returns ;;; nil! ;;; Code: (if (not (equal system-type 'windows-nt)) (message "stdname.el is only for Windows 95 (and Windows NT?)") (require 'advice) (defun standard-file-name ( name ) (let* ((sep-char (char-to-string directory-sep-char)) (unc-regexp (concat "^" sep-char sep-char))) (cond ;; do nothing if NAME starts with two backslashes since this could ;; be a file system which is case sensitive such as unix. ((string-match unc-regexp name) name) (t (downcase name) ;;(upcase name) ;; if you prefer uppercase filenames. )))) (defadvice find-file-noselect (before lowercase-names activate compile) "Standardize file name to minimize duplicate buffers." (setq filename (standard-file-name filename))) ) (provide 'stdname) ;;; stdname.el ends here Richard Y. Kim Audio Precision ryk@ap.com From owner-ntemacs-users@june Sat Sep 7 07:19:12 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Sat" " 7" "September" "1996" "14:33:46" "+0100" "Andrew Innes" "andrewi@harlequin.co.uk" nil "19" "Re: find-file-existing-other-name doesn't work in 19.33 (was Case sensitivity in etags)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id HAA01772 for ; Sat, 7 Sep 1996 07:19:12 -0700 Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id HAA19436 for ; Sat, 7 Sep 1996 07:19:09 -0700 Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id GAA28865 for ; Sat, 7 Sep 1996 06:34:29 -0700 Received: from propos.long.harlequin.co.uk by holly.cam.harlequin.co.uk; Sat, 7 Sep 1996 14:33:48 +0100 Received: from elan.long.harlequin.co.uk (elan [193.128.93.78]) by propos.long.harlequin.co.uk (8.6.12/8.6.12) with SMTP id OAA08649; Sat, 7 Sep 1996 14:33:46 +0100 Message-Id: <199609071333.OAA08649@propos.long.harlequin.co.uk> In-Reply-To: <199609070049.RAA15449@audiotst.ap.com> (ryk@ap.com) From: Andrew Innes To: ryk@ap.com Cc: rbrodersen@siebel.com, ryk@audiotst.ap.com, ntemacs-users@cs.washington.edu Subject: Re: find-file-existing-other-name doesn't work in 19.33 (was Case sensitivity in etags) Date: Sat, 7 Sep 1996 14:33:46 +0100 On Fri, 6 Sep 1996 17:49:07 -0700, "Richard Y. Kim" said: > >I posted this many months ago before 19.31 was released. >I have made some changes to make it work with 19.31 and up. >I don't know whether this is obsoleted by find-file-existing-other-name >or not, but this has served me well for several months. [ .. ] >;;; Bugs: >;;; I think stdname.el should be disabled for NT, but I don't know how >;;; to distinguish win95 verses nt in emacs-lisp. >;;; On my ntemacs-19.33 running on Windows 95, (getenv "winbasedir") returns >;;; nil! Use (getenv "winbootdir") instead. That returns nil on NT and a string on Win95. AndrewI From storm@olicom.dk Mon Sep 16 01:25:57 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "16" "September" "1996" "10:24:42" "+0200" "Kim F. Storm" "storm@olicom.dk" nil "56" "find-file-existing-other-name / file-alias-p (again!)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from olicom.olicom.dk (eolicom.olicom.dk [194.255.19.1]) by june.cs.washington.edu (8.7.5/7.2ju) with ESMTP id BAA01431 for ; Mon, 16 Sep 1996 01:25:54 -0700 Received: from kfs.olicom.dk (kfs.olicom.dk [172.16.99.27]) by olicom.olicom.dk (8.7.5/8.7.3/efh.2.16) with SMTP id KAA02000; Mon, 16 Sep 1996 10:24:42 +0200 (MET DST) Message-Id: <199609160824.KAA02000@olicom.olicom.dk> In-reply-to: <199609142107.RAA01868@ethanol.gnu.ai.mit.edu> (message from Richard Stallman on Sat, 14 Sep 1996 17:07:24 -0400) From: "Kim F. Storm" To: rms@gnu.ai.mit.edu Cc: voelker@cs.washington.edu, andrewi@harlequin.co.uk, eliz@is.elta.co.il Subject: find-file-existing-other-name / file-alias-p (again!) 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 From eliz@is.elta.co.il Mon Sep 16 02:20:42 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "16" "September" "1996" "12:19:14" "+0200" "Eli Zaretskii" "eliz@is.elta.co.il" nil "29" "Re: find-file-existing-other-name / file-alias-p (again!)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from is.elta.co.il (is.elta.co.il [199.203.121.2]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id CAA06230 for ; Mon, 16 Sep 1996 02:20:38 -0700 Received: by is.elta.co.il (5.x/SMI-SVR4) id AA22058; Mon, 16 Sep 1996 12:19:15 +0200 X-Sender: eliz@is In-Reply-To: <199609160824.KAA02000@olicom.olicom.dk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Eli Zaretskii To: "Kim F. Storm" Cc: rms@gnu.ai.mit.edu, voelker@cs.washington.edu, andrewi@harlequin.co.uk Subject: Re: find-file-existing-other-name / file-alias-p (again!) Date: Mon, 16 Sep 1996 12:19:14 +0200 (IST) On Mon, 16 Sep 1996, Kim F. Storm wrote: > 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. 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 rms@gnu.ai.mit.edu Mon Sep 16 02:48:17 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "16" "September" "1996" "05:46:00" "-0400" "Richard Stallman" "rms@gnu.ai.mit.edu" nil "6" "Re: find-file-existing-other-name / file-alias-p (again!)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from ethanol.gnu.ai.mit.edu (ethanol.gnu.ai.mit.edu [128.52.46.64]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id CAA08847 for ; Mon, 16 Sep 1996 02:48:07 -0700 Received: by ethanol.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id FAA08837; Mon, 16 Sep 1996 05:46:00 -0400 Message-Id: <199609160946.FAA08837@ethanol.gnu.ai.mit.edu> In-reply-to: <199609160824.KAA02000@olicom.olicom.dk> (storm@olicom.dk) From: Richard Stallman To: storm@olicom.dk CC: voelker@cs.washington.edu, andrewi@harlequin.co.uk, eliz@is.elta.co.il Subject: Re: find-file-existing-other-name / file-alias-p (again!) Date: Mon, 16 Sep 1996 05:46:00 -0400 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). Would it be appropriate for file-truename to do these things on systems where they are called for? From storm@olicom.dk Mon Sep 16 06:03:50 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "16" "September" "1996" "15:03:16" "+0200" "Kim F. Storm" "storm@olicom.dk" nil "18" "Re: find-file-existing-other-name / file-alias-p (again!)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from olicom.olicom.dk (eolicom.olicom.dk [194.255.19.1]) by june.cs.washington.edu (8.7.5/7.2ju) with ESMTP id GAA19247 for ; Mon, 16 Sep 1996 06:03:47 -0700 Received: from kfs.olicom.dk (kfs.olicom.dk [172.16.99.27]) by olicom.olicom.dk (8.7.5/8.7.3/efh.2.16) with SMTP id PAA20519; Mon, 16 Sep 1996 15:03:16 +0200 (MET DST) Message-Id: <199609161303.PAA20519@olicom.olicom.dk> In-reply-to: <199609160946.FAA08837@ethanol.gnu.ai.mit.edu> (message from Richard Stallman on Mon, 16 Sep 1996 05:46:00 -0400) From: "Kim F. Storm" To: rms@gnu.ai.mit.edu CC: storm@olicom.dk, voelker@cs.washington.edu, andrewi@harlequin.co.uk, eliz@is.elta.co.il Subject: Re: find-file-existing-other-name / file-alias-p (again!) Date: Mon, 16 Sep 1996 15:03:16 +0200 (MET DST) Date: Mon, 16 Sep 1996 05:46:00 -0400 From: Richard Stallman Cc: voelker@cs.washington.edu, andrewi@harlequin.co.uk, eliz@is.elta.co.il 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). Would it be appropriate for file-truename to do these things on systems where they are called for? 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). -- Kim F. Storm, Olicom A/S From storm@olicom.dk Mon Sep 16 06:28:57 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "16" "September" "1996" "15:27:57" "+0200" "Kim F. Storm" "storm@olicom.dk" nil "79" "Re: find-file-existing-other-name / file-alias-p (again!)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from olicom.olicom.dk (eolicom.olicom.dk [194.255.19.1]) by june.cs.washington.edu (8.7.5/7.2ju) with ESMTP id GAA21224 for ; Mon, 16 Sep 1996 06:28:54 -0700 Received: from kfs.olicom.dk (kfs.olicom.dk [172.16.99.27]) by olicom.olicom.dk (8.7.5/8.7.3/efh.2.16) with SMTP id PAA22436; Mon, 16 Sep 1996 15:27:57 +0200 (MET DST) Message-Id: <199609161327.PAA22436@olicom.olicom.dk> In-reply-to: (message from Eli Zaretskii on Mon, 16 Sep 1996 12:19:14 +0200 (IST)) From: "Kim F. Storm" To: eliz@is.elta.co.il CC: rms@gnu.ai.mit.edu, voelker@cs.washington.edu, andrewi@harlequin.co.uk Subject: Re: find-file-existing-other-name / file-alias-p (again!) Date: Mon, 16 Sep 1996 15:27:57 +0200 (MET DST) Date: Mon, 16 Sep 1996 12:19:14 +0200 (IST) From: Eli Zaretskii > 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. 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). 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... 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. 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. 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. 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. -- Kim F. Storm, Olicom A/S From eliz@is.elta.co.il Mon Sep 16 08:02:16 1996 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "16" "September" "1996" "18:00:57" "+0200" "Eli Zaretskii" "eliz@is.elta.co.il" nil "61" "Re: find-file-existing-other-name / file-alias-p (again!)" "^From:" nil nil "9" nil nil nil nil] nil) Received: from is.elta.co.il (is.elta.co.il [199.203.121.2]) by june.cs.washington.edu (8.7.5/7.2ju) with SMTP id IAA27817 for ; Mon, 16 Sep 1996 08:02:12 -0700 Received: by is.elta.co.il (5.x/SMI-SVR4) id AA00504; Mon, 16 Sep 1996 18:00:58 +0200 X-Sender: eliz@is In-Reply-To: <199609161327.PAA22436@olicom.olicom.dk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Eli Zaretskii To: "Kim F. Storm" Cc: rms@gnu.ai.mit.edu, voelker@cs.washington.edu, andrewi@harlequin.co.uk Subject: Re: find-file-existing-other-name / file-alias-p (again!) Date: Mon, 16 Sep 1996 18:00:57 +0200 (IST) On Mon, 16 Sep 1996, Kim F. Storm wrote: > 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). 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. > 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. 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. > 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. 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. > 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. 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.