From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.bugs Subject: bug#21816: elisp-mode-tests fails on a case-preserving filesystem Date: Wed, 04 Nov 2015 13:14:31 -0600 Message-ID: <86h9l1y3u0.fsf@stephe-leake.org> References: <86mvuv30i1.fsf@stephe-leake.org> <86y4ef16ha.fsf@stephe-leake.org> <83d1vrw0p9.fsf@gnu.org> <5638D836.8090600@yandex.ru> <5638DE4A.308@yandex.ru> <86h9l2270y.fsf@stephe-leake.org> <83h9l2vloe.fsf@gnu.org> <864mh2219i.fsf@stephe-leake.org> <83d1vqv3af.fsf@gnu.org> <86y4eexew5.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446666035 27656 80.91.229.3 (4 Nov 2015 19:40:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Nov 2015 19:40:35 +0000 (UTC) Cc: lekktu@gmail.com, 21816@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 04 20:40:23 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zu3uo-0007vX-Tu for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Nov 2015 20:40:15 +0100 Original-Received: from localhost ([::1]:56854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu3uo-0008LC-9n for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Nov 2015 14:40:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu3uk-0008Iw-0t for bug-gnu-emacs@gnu.org; Wed, 04 Nov 2015 14:40:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zu3ud-0002Z3-V7 for bug-gnu-emacs@gnu.org; Wed, 04 Nov 2015 14:40:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu3ud-0002Yy-Rx for bug-gnu-emacs@gnu.org; Wed, 04 Nov 2015 14:40:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zu3ud-0004lN-6l for bug-gnu-emacs@gnu.org; Wed, 04 Nov 2015 14:40:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Leake Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Nov 2015 19:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21816 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21816-submit@debbugs.gnu.org id=B21816.144666597318266 (code B ref 21816); Wed, 04 Nov 2015 19:40:02 +0000 Original-Received: (at 21816) by debbugs.gnu.org; 4 Nov 2015 19:39:33 +0000 Original-Received: from localhost ([127.0.0.1]:53689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zu3u8-0004kY-Tc for submit@debbugs.gnu.org; Wed, 04 Nov 2015 14:39:33 -0500 Original-Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:53889) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1Zu3u5-0004kN-5q for 21816@debbugs.gnu.org; Wed, 04 Nov 2015 14:39:30 -0500 Original-Received: (qmail 20534 invoked by uid 0); 4 Nov 2015 19:39:24 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 4 Nov 2015 19:39:24 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id dXfJ1r00m2UdiVW01XfMJL; Wed, 04 Nov 2015 12:39:24 -0700 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=HMPm_nkzBoqVwBawQJwA:9 Original-Received: from [76.218.37.33] (port=58971 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zu3WB-0005DF-Kh; Wed, 04 Nov 2015 12:14:47 -0700 In-Reply-To: <86y4eexew5.fsf@stephe-leake.org> (Stephen Leake's message of "Wed, 04 Nov 2015 04:00:58 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108456 Archived-At: I've now looked at the definition of `file-equal-p': (let ((handler (or (find-file-name-handler file1 'file-equal-p) (find-file-name-handler file2 'file-equal-p)))) (if handler (funcall handler 'file-equal-p file1 file2) (let (f1-attr f2-attr) (and (setq f1-attr (file-attributes (file-truename file1))) (setq f2-attr (file-attributes (file-truename file2))) (equal f1-attr f2-attr)))))) This implies there are two reasons why `file-truename' (and by extension `file-canonical-name') is not sufficient for determining if two names identify the same file. I think one issue is hardlinks; a file can have two distinct truenames because of hardlinks, but the attributes contain the uid and the inode number, which will identify the actual file. I'm not clear on why a special handler for file-equal-p is needed; is that just an optimization? file-truename respects file handlers. This changes Option 2 as indicated below. Stephen Leake writes: > To summarize: > > The problem is comparing xrefs directly (for sorting and testing), > comparing the result of xref-location-group (for sorting), and possibly > comparing results of other xref access functions in the future. Note > that any filenames in xrefs identify existing files, except in > artifically constructed tests. > > I believe the two alternatives being proposed are: > > 1) Use `file-equal-p' > > - Provide a cl-defgeneric `xref-location-equal-p' for the root > xref-location type. > > - For each type that inherits from xref-location, provide an > implementation of `xref-location-equal-p' that uses `file-equal-p' for > each file name. > > - Provide a cl-defmethod `xref-equal-p' for the root xref type that uses > `xref-location-equal-p' for the location. > > - For each type that inherits from xref, provide an implementation of > `xref-equal-p' that uses `xref-location-equal-p' for each location. > > > 2) Use `file-canonical-name' This changes to "Use `file-truename'. > - A canonical file name has the following features: > > It contains forward slashes for directory separators. > > If the file name identifies an existing file, the canonical file name > casing matches the actual file name casing. If not, the case of the > portions of the canonical file name that do not exist is arbitrary. > Note that this matters only on case-insensitive file systems. I believe this is true of the result of file-truename, and it could be added to the docstring for that function. The following two points cannot be satisfied in the presence of hardlinks, and possibly other issues with file handlers; so they are deleted. > Two different non-canonical names for an existing file convert to the > same canonical file name. Note that this means symlinks are resolved. > > Canonical file names may be compared with `string-equal' and > `string-lessp'. > - Provide a system-dependent `file-canonical-name' that converts > user-provided file names to a canonical file name. This is deleted. > - Require each variant of make-xref-location to use it for file name > slots. "it" now means "file-truename". > Option 1) solves the problem of comparing xrefs and xref-locations, but > does not solve the problem of comparing results of > xref-location-group. This remains true. And since xref--analyze compares the result of xref-location-group, it is not just a theoretical problem; I provided an example where it fails. > Option 2) solves the problems of comparing xrefs, xref-locations, > results of xref-location-group, and results of future xref access > functions. This is true only if there are no hard links (or other issues with file handlers). > So far, `file-truename' seems adequate for `file-canonical-name', but it > might be best to define the alias, in case we find problems in the > future. This is not true; I'm now convinced it is not possible to define a fully correct `file-canonical-name'. Hmm. If there is a way to iterate all the truenames for a file (I didn't find one), then we could order them with string-lessp, and simply take the first as the canonical name. I'm not sure that would be really useful. > Option 2) seems better to me. This remains true. If there are hardlinks on the disk, users will just have to be aware of that, and cope. That's no worse than the current situation. -- -- Stephe