GNU bug report logs - #10489
24.0.92; dired-do-copy may create infinite directory hierarchy

Previous Next

Full log

View this message in rfc822 format

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10489 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: bug#10489: 24.0.92; dired-do-copy may create infinite directory hierarchy
Date: Wed, 22 Feb 2012 22:37:24 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> 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.

Ok, that is true for the solutions you propose below, but what's wrong
with the solution I have proposed:
Just checking if the destination directory is a subdirectory of the
directory we want to copy.

>>> 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.
If we do not have to follow this, I would prefer not starting copying
stuff the user will have to remove afterward when he realize it was
an error (i.e copying a directory on itself).

> 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.
This may be slow isn't it?

>>> 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").

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.