From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#10489: 24.0.92; dired-do-copy may create infinite directory hierarchy Date: Sat, 14 Jan 2012 09:19:51 -0500 Message-ID: References: <87mx9su32g.fsf@web.de> <87sjjkfvwt.fsf@gmail.com> <8362ggkquq.fsf@gnu.org> <87lipcrlga.fsf@gmail.com> <87fwfkc4pn.fsf@gmx.de> <87fwfjsw8t.fsf@gmail.com> <87aa5rdazl.fsf@gmx.de> <87d3anogf5.fsf@gmail.com> <011AEED9E81C4DEFA6B1E03B0F57F28F@us.oracle.com> <878vlbljnc.fsf@gmx.de> <8739bj8mu1.fsf@gmail.com> <8762gfnrlj.fsf@gmx.de> <83aa5qk6co.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1326550832 3301 80.91.229.12 (14 Jan 2012 14:20:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2012 14:20:32 +0000 (UTC) Cc: 10489@debbugs.gnu.org, michael.albinus@gmx.de, thierry.volpiatto@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 14 15:20:27 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rm4T2-0001cu-B8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jan 2012 15:20:24 +0100 Original-Received: from localhost ([::1]:44705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm4T1-0003U2-PO for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jan 2012 09:20:23 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm4Sy-0003Tx-8S for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2012 09:20:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rm4Sx-0000wO-9h for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2012 09:20:20 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm4Sx-0000wK-6u for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2012 09:20:19 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Rm4Td-0005IV-R0 for bug-gnu-emacs@gnu.org; Sat, 14 Jan 2012 09:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jan 2012 14:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10489 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10489-submit@debbugs.gnu.org id=B10489.132655084820343 (code B ref 10489); Sat, 14 Jan 2012 14:21:01 +0000 Original-Received: (at 10489) by debbugs.gnu.org; 14 Jan 2012 14:20:48 +0000 Original-Received: from localhost ([127.0.0.1]:57173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rm4TO-0005I3-Tt for submit@debbugs.gnu.org; Sat, 14 Jan 2012 09:20:47 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:42338) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rm4TI-0005Hl-7l for 10489@debbugs.gnu.org; Sat, 14 Jan 2012 09:20:44 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIKNEU9FxKkV/2dsb2JhbABDqwKCMoEGgXIBAQQBViMFCws0EhQYDSSIDbYojBcEiDuaY4RS X-IronPort-AV: E=Sophos;i="4.71,509,1320642000"; d="scan'208";a="156750079" Original-Received: from 69-196-169-21.dsl.teksavvy.com (HELO pastel.home) ([69.196.169.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 14 Jan 2012 09:19:51 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 40B0D59439; Sat, 14 Jan 2012 09:19:51 -0500 (EST) In-Reply-To: <83aa5qk6co.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Jan 2012 10:59:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.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:55734 Archived-At: > > I don't mean "document what the code currently does" but "document > > what the code should do". > Same thing in this case. I was just pointing out that basing the docstring on a sample implementation is not the right way to do it. > If we want to resolve the various cases of equivalent file names, we > have no alternative but hitting the disk. IIRC that's indeed the case if we want to consider equal the VFAT file systems monste~1. And that's exactly the kind of thing I want us to decide by writing the docstring. For POSIX the same question comes up with symlinks. >> > "Return non-nil if NAME1 and NAME2 refer to the same file in the >> > file system. If either name is not absolute, then it is expanded >> > relative to DIR (if given) or `default-directory' for the test." >> That description is too vague: an implementation based on comparing >> file-attributes would seem to fit, whereas it's clearly not the semantic >> we want to provide. > Sorry, I'm not following. Why does a possibly different > implementation make the doc string "too vague"? IOW, the doc string > _should_ be sufficiently "vague" to allow a change in the > implementation without breaking the API or the semantics, right? To me "the same name" is something quite different from "the same file". I think file-name-equal-p should make it clear that it means "same name" and not "same file" because we may want to use it without knowing if the file exists and without opening a remote connection. IIUC the original problem in dired-do-copy needs to test "same file" rather than "same name", so it should not use file-name-equal-p but file-equal-p (which would rely on file-attributes, presumably). Stefan