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: Tue, 21 Feb 2012 17:51:21 -0500 Message-ID: References: <87mx9su32g.fsf@web.de> <8739bj8mu1.fsf@gmail.com> <87fwfjo24c.fsf@gmx.de> <87pqen76p4.fsf@gmail.com> <83fwfik92e.fsf@gnu.org> <87mx9q1sz7.fsf@gmail.com> <87vcodm8ns.fsf@gmx.de> <87pqekopb5.fsf@gmail.com> <87hazwoost.fsf@gmail.com> <87ty3w9639.fsf@gmx.de> <8762gckckt.fsf@gmail.com> <87pqek9269.fsf@gmx.de> <87r4z0yqfx.fsf@gmail.com> <871uqzn3bc.fsf@gmx.de> <871uqz651u.fsf@gmx.de> <87pqd89lh4.fsf@gmail.com> <87mx8b3nvb.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1329864712 9702 80.91.229.3 (21 Feb 2012 22:51:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2012 22:51:52 +0000 (UTC) Cc: 10489@debbugs.gnu.org, Michael Albinus To: Thierry Volpiatto Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 21 23:51:50 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RzyYn-0003Ju-8k for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Feb 2012 23:51:49 +0100 Original-Received: from localhost ([::1]:33399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzyYm-0004hG-Ku for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Feb 2012 17:51:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzyYi-0004h8-VP for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2012 17:51:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzyYh-0002kN-PJ for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2012 17:51:44 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzyYh-0002kF-Nm for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2012 17:51:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Rzyav-0007v4-Uz for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2012 17:54: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: Tue, 21 Feb 2012 22:54: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: patch Original-Received: via spool by 10489-submit@debbugs.gnu.org id=B10489.132986482930424 (code B ref 10489); Tue, 21 Feb 2012 22:54:01 +0000 Original-Received: (at 10489) by debbugs.gnu.org; 21 Feb 2012 22:53:49 +0000 Original-Received: from localhost ([127.0.0.1]:49347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rzyaj-0007uf-Ec for submit@debbugs.gnu.org; Tue, 21 Feb 2012 17:53:49 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39220) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rzyag-0007uS-UR for 10489@debbugs.gnu.org; Tue, 21 Feb 2012 17:53:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAIgfRE9Ld/XJ/2dsb2JhbAA6Ca9GgnuBCIFzAQEEAVYjBQsLNBIUGA0kLodluEKJXIJ0CQwCg2IGCwQRg1AEiE+bGYRb X-IronPort-AV: E=Sophos;i="4.73,460,1325480400"; d="scan'208";a="164114551" Original-Received: from 75-119-245-201.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.201]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 21 Feb 2012 17:51:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id B7FA5590F9; Tue, 21 Feb 2012 17:51:21 -0500 (EST) In-Reply-To: <87mx8b3nvb.fsf@gmail.com> (Thierry Volpiatto's message of "Tue, 21 Feb 2012 21:58:16 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (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:57055 Archived-At: >>> so what is the state of this bug and what do you plan for this? >> >>> As a reminder, we needed: >> >>> 1) A function to compare filenames locally. >>> 2) A tramp handler for this function. >>> 3) A function to check if file1 is subdir of file2, locally also. >>> 4) A tramp handler for this one also? >> >>> We have more or less 1 and 3, need tramp handlers for them. >> >>> What else is needed? >> >> Just before we try and solve this problem the hard way: >> I just tried: >> >> % ln -s erlang-otp erl >> % cp -r erl/lib erlang-otp/lib/inviso/ > We have to check if "erlang-otp/lib/inviso/" is a subdir of "erl/lib" > to resolve this, right? No, we just have to check if during the recursive copy we're trying to read one of the directories we've just made. >> So it seems that the coreutils guys have found it sufficient to detect >> the inf-loop after the fact and interrupt the operation at that point >> rather than to try and predict that the cp will loop and don't perform >> it at all. > Do we have to strictly follow this? No, it's just an alternative approach. The potential advantage is that it does not require figuring out whether a file is within some directory, it only requires checking actual equality between two directories. Another approach is to first get the complete list of files and only copy them afterwards. This doesn't require any comparison at all and completely avoids the risk of inf-loop. >> It might be easier to get a solution that catches all cases that way: >> remember the name and identity (inode/file-attributes/younameit) of >> the top directory we create, > "erl/lib"? No, we don't create erl/lib (it's the source instead), the top-level dir we create is "erlang-otp/lib/inviso/lib". >> and whenever we're about to copy a directory of the same name, > Not sure to fully understand this, do you mean "and whenever we're > about to copy the CONTENTS of a directory of the same name?" In the recursive loop, the distinction between copying a directory and copying its contents is not really relevant to this problem (the recursive call says "copy foo and its contents"). Stefan