GNU logs - #18491, boring messages

Message sent to bug-coreutils@HIDDEN:

Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Resent-From: Gian Ntzik <gian.ntzik08@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 17 Sep 2014 19:42:02 +0000
Resent-Message-ID: <handler.18491.B.141098289223669 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 18491 <at> debbugs.gnu.org
From: Gian Ntzik <gian.ntzik08@HIDDEN>
Date: Wed, 17 Sep 2014 06:38:56 +0100
Message-ID: <87sijqbybz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hello,

It seems that using rm -r with a path that goes into a (non-empty)
directory intended for removal (and back up e.g. using dot-dots) fails
to remove the directory. The directory is rendered empty, but itself not
removed.

For example,

$ mkdir -p /tmp/a/b/c
$ mkdir -p /tmp/a/e
$ rm -r /tmp/a/b/../../a
rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory

Then,

$ ls /tmp/a

yeilds empty contents, and

$ ls -d /tmp/a
/tmp/a

yields that the directory intended for removal still exists.

I have tested this in Ubuntu 14.04 where coreutils is at version 8.21. I
have also tested it with version 8.23 built from source also on Ubuntu
14.04.

I do not believe this is the intended behavior, but a bug.

Obviously, once the contents of /tmp/a have been removed, the path
/tmp/a/b/../../a is no longer resolvable. However, the same applies for
any sub-directory of /tmp/a. For example, once /tmp/a/b has been
removed, /tmp/a/b/../../a/e is also no longer resolvable. It seems that
rm -r takes care to avoid such issues during recursion but fails to do
so at the very end.

Thank you,

Gian Ntzik

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Gian Ntzik <gian.ntzik08@HIDDEN>
Subject: bug#18491: Acknowledgement (rm -r fails to delete entire
 hierarchy when path goes in and out of it)
Message-ID: <handler.18491.B.141098289223669.ack <at> debbugs.gnu.org>
References: <87sijqbybz.fsf@HIDDEN>
X-Gnu-PR-Message: ack 18491
X-Gnu-PR-Package: coreutils
Reply-To: 18491 <at> debbugs.gnu.org
Date: Wed, 17 Sep 2014 19:42:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-coreutils@HIDDEN

If you wish to submit further information on this problem, please
send it to 18491 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
18491: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18491
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-coreutils@HIDDEN:

Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 17 Sep 2014 20:09:02 +0000
Resent-Message-ID: <handler.18491.B18491.141098450726511 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Gian Ntzik <gian.ntzik08@HIDDEN>, 18491 <at> debbugs.gnu.org
Message-ID: <5419EA2F.9000003@HIDDEN>
Date: Wed, 17 Sep 2014 13:08:15 -0700
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
References: <87sijqbybz.fsf@HIDDEN>
In-Reply-To: <87sijqbybz.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On 09/16/2014 10:38 PM, Gian Ntzik wrote:
> It seems that
> rm -r takes care to avoid such issues during recursion but fails to do
> so at the very end.

A clever example but it's not clear it's a bug, or how to "fix" it.  For 
what it's worth, Solaris 10 /bin/rm behaves the same way.

Message sent to bug-coreutils@HIDDEN:

Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Resent-From: Bob Proulx <bob@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 18 Sep 2014 21:29:01 +0000
Resent-Message-ID: <handler.18491.B18491.141107568629304 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Gian Ntzik <gian.ntzik08@HIDDEN>
Cc: 18491 <at> debbugs.gnu.org
Date: Thu, 18 Sep 2014 15:28:01 -0600
From: Bob Proulx <bob@HIDDEN>
Message-ID: <20140918151521298129111@HIDDEN>
References: <87sijqbybz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87sijqbybz.fsf@HIDDEN>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Gian Ntzik wrote:
> It seems that using rm -r with a path that goes into a (non-empty)
> directory intended for removal (and back up e.g. using dot-dots) fails
> to remove the directory. The directory is rendered empty, but itself not
> removed.
> 
> For example,
> 
> $ mkdir -p /tmp/a/b/c
> $ mkdir -p /tmp/a/e
> $ rm -r /tmp/a/b/../../a
> rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory

I don't think this can reasonably be called a bug.  A depth first
removal is required.  a/b must be removed before a is removed.  But
the relative reference requires a/b to exist in order to obtain
b/.. in order to obtain b/../.. in order to obtain b/../../a but a/b
gets removed first since a depth first removal is required.

Trying to do anything to work around this seems wrong to me since it
will require keeping track of the state before and simulating to
create the desired state afterward and then applying a derived state
change to the file system.  That is much too complex for this simple
operation.

> Obviously, once the contents of /tmp/a have been removed, the path
> /tmp/a/b/../../a is no longer resolvable. However, the same applies for
> any sub-directory of /tmp/a. For example, once /tmp/a/b has been
> removed, /tmp/a/b/../../a/e is also no longer resolvable. It seems that
> rm -r takes care to avoid such issues during recursion but fails to do
> so at the very end.

I don't think it matters that a/e and a/b do actually get removed
revealing that in the implementation some ordering is happening.
Regardless of that I don't think it is reasonable to require that rm
remember the old path through a relative path that gets removed along
the way.

Bob

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in	and out of it
Resent-From: "Linda A. Walsh" <coreutils@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 18 Sep 2014 23:42:02 +0000
Resent-Message-ID: <handler.18491.B18491.14110837039720 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18491
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Bob Proulx <bob@HIDDEN>
Cc: Gian Ntzik <gian.ntzik08@HIDDEN>, 18491 <at> debbugs.gnu.org
Received: via spool by 18491-submit <at> debbugs.gnu.org id=B18491.14110837039720
          (code B ref 18491); Thu, 18 Sep 2014 23:42:02 +0000
Received: (at 18491) by debbugs.gnu.org; 18 Sep 2014 23:41:43 +0000
Received: from localhost ([127.0.0.1]:44887 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XUlKY-0002Wi-JY
	for submit <at> debbugs.gnu.org; Thu, 18 Sep 2014 19:41:43 -0400
Received: from ishtar.tlinx.org ([173.164.175.65]:34994
 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <coreutils@HIDDEN>) id 1XUlKV-0002WY-7k
 for 18491 <at> debbugs.gnu.org; Thu, 18 Sep 2014 19:41:40 -0400
Received: from [192.168.4.12] (athenae [192.168.4.12])
 by Ishtar.hs.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id
 s8INeeSB062640; Thu, 18 Sep 2014 16:40:42 -0700
Message-ID: <541B6D79.7050409@HIDDEN>
Date: Thu, 18 Sep 2014 16:40:41 -0700
From: "Linda A. Walsh" <coreutils@HIDDEN>
User-Agent: Thunderbird
MIME-Version: 1.0
References: <87sijqbybz.fsf@HIDDEN>
 <20140918151521298129111@HIDDEN>
In-Reply-To: <20140918151521298129111@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Bob Proulx wrote:
> Gian Ntzik wrote:
>> It seems that using rm -r with a path that goes into a (non-empty)
>> directory intended for removal (and back up e.g. using dot-dots) fails
>> to remove the directory. The directory is rendered empty, but itself not
>> removed.
>>
>> For example,
>>
>> $ mkdir -p /tmp/a/b/c
>> $ mkdir -p /tmp/a/e
>> $ rm -r /tmp/a/b/../../a
>> rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory
>
> I don't think this can reasonably be called a bug.  A depth first
> removal is required. 
----
    I would tend to agree, but if you try to remove /tmp/a/.
a "depth first removal" won't be tried -- so it is obviously not required.

>
> Trying to do anything to work around this seems wrong to me since it
> will require keeping track of the state before and simulating to
> create the desired state afterward and then applying a derived state
> change to the file system.  That is much too complex for this simple
> operation.
----
    One would think the same for rm -fr "foo/.", but the
straight-forward application of the depth-first removal was
removed from "rm" for special cases.  One would think
that the underlying tree might be easily addressed:

function rmr {
  local rd=$(cd "$1"; /bin/pwd)
  echo rm -r "$rd"
}

same dir struct as above:
>  tree /tmp/a
/tmp/a
├── b
│   └── c
└── e

>  rmr /tmp/a
rm -r /tmp/a

---
If rm should delete  the directory and its contents as it is documented
to do except where POSIX prohibits it, (like  "rm -fr dir/."),
then except for POSIX instructions to the contrary, it seems it
should make at least as trivial an effort as the above.  :-|

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Resent-From: Gian Ntzik <gian.ntzik08@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 19 Sep 2014 03:31:02 +0000
Resent-Message-ID: <handler.18491.B18491.141109743819586 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18491
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Bob Proulx <bob@HIDDEN>
Cc: "18491 <at> debbugs.gnu.org" <18491 <at> debbugs.gnu.org>
Received: via spool by 18491-submit <at> debbugs.gnu.org id=B18491.141109743819586
          (code B ref 18491); Fri, 19 Sep 2014 03:31:02 +0000
Received: (at 18491) by debbugs.gnu.org; 19 Sep 2014 03:30:38 +0000
Received: from localhost ([127.0.0.1]:45032 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XUou5-00055o-Is
	for submit <at> debbugs.gnu.org; Thu, 18 Sep 2014 23:30:38 -0400
Received: from smtp1.cc.ic.ac.uk ([155.198.5.155]:46432)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XUou1-00055b-GY
 for 18491 <at> debbugs.gnu.org; Thu, 18 Sep 2014 23:30:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=imperial.ac.uk; s=main01; 
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From;
 bh=jJKc4ZAv7VMBkhDUsZzE2pqX+nWNpzLHIaJcxjMTag4=; 
 b=cF5IG/sQIvQwa26ftjdkni7S/F8rQ4Fx5sp090BeJto9iShWdNNUtF2EjfI/a8wqRPJE1aSrzKR9KILe/X4jdbt+RCWieOcdEVQIByJKmFnYESG7hbINuL+Vuwh9f5lYK4DzF+icThjUfWWTEGtn/GmABKfE/dFvfss6EXG1Kpc=;
Received: from [176.251.158.159] (helo=localhost)
 by smtp1.cc.ic.ac.uk with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128)
 (Exim 4.82.1) (envelope-from <gian.ntzik08@HIDDEN>)
 id 1XUoty-0006MN-4l; Fri, 19 Sep 2014 04:30:31 +0100
From: Gian Ntzik <gian.ntzik08@HIDDEN>
References: <87sijqbybz.fsf@HIDDEN>
 <d516fd37c11e44969db68dd466aa3729@HIDDEN>
Date: Fri, 19 Sep 2014 04:30:29 +0100
In-Reply-To: <d516fd37c11e44969db68dd466aa3729@HIDDEN> (Bob
 Proulx's message of "Thu, 18 Sep 2014 21:28:01 +0000")
Message-ID: <87fvfob82y.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IC-MsgID: 1XUoty-0006MN-4l
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Bob Proulx <bob@HIDDEN> writes:

> Gian Ntzik wrote:
>> It seems that using rm -r with a path that goes into a (non-empty)
>> directory intended for removal (and back up e.g. using dot-dots) fails
>> to remove the directory. The directory is rendered empty, but itself not
>> removed.
>> 
>> For example,
>> 
>> $ mkdir -p /tmp/a/b/c
>> $ mkdir -p /tmp/a/e
>> $ rm -r /tmp/a/b/../../a
>> rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory

Bear in mind that the issue is not restricted to dot-dots within the
pathname argument. The problem is with any pathname that traverses
the same directory we want to remove. The same thing can happen with
symlinks.

For example,
$ mkdir -p /tmp/a/b/c
$ mkdir -p /tmp/a/e
$ ln -s /tmp /tmp/a/e/x
$ ls /tmp/a
b  e
$ ls /tmp/a/e/x/a
b  e
$ rm -r /tmp/a/e/x/a
rm: cannot remove ‘/tmp/a/e/x/a’: No such file or directory
$ ls /tmp/a
$

> I don't think this can reasonably be called a bug.  

Assume this is not a bug as you claim. 

Then this means that given an acceptable path argument (not ending in dot,
dot-dot and not resolving to /) that successfully resolves to a
directory, rm -r may or may not delete the directory (assuming no
interference from a concurrently running process). So, either your rm -r
behaviour is non-deterministic even without concurrency, or rm -r is not
intended to be used by all acceptable paths, but by some subset
satisfying a property P.

A definition of this property P could be:
Path x satisfies P iff 
x is acceptable by rm, and
if x resolves to a directory then, there does not exist a prefix y of x
such that y resolves to the same entry as x.

For paths not satisfying P, rm -r does something else, or is
undefined.

There are two major problems with is:
1). This usage restriction is not mentioned in this implementation's
documentation. If this is not a bug then it really should, because
clients of rm wanting to really remove a directory must make sure their
paths meet your requirements.
2). The POSIX rm specification does not restrict the paths that can be
used to remove directories (other than those that rm does not accept in
the first place). In fact this most probably deviates from the standard.

>
> Trying to do anything to work around this seems wrong to me since it
> will require keeping track of the state before and simulating to
> create the desired state afterward and then applying a derived state
> change to the file system.  That is much too complex for this simple
> operation.
>

Yes, this is way too complex. However, for every path there is a
canonical path that does not use dot-dots or reference symbolic
links. Canonical paths would never run into such problems because they
do not traverse what they resolve to. After initial checks to see if the
argument is acceptable (not ending in dot-dot, dot or not being /), one
could take the canonical path of the argument, e.g. through a simple
realpath(), and start the recursive removal with that. This seems much
simpler.

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Resent-From: Gian Ntzik <gian.ntzik08@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 19 Sep 2014 03:48:02 +0000
Resent-Message-ID: <handler.18491.B18491.141109846722147 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18491
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: "Linda A. Walsh" <coreutils@HIDDEN>
Cc: "18491 <at> debbugs.gnu.org" <18491 <at> debbugs.gnu.org>, Bob Proulx <bob@HIDDEN>
Received: via spool by 18491-submit <at> debbugs.gnu.org id=B18491.141109846722147
          (code B ref 18491); Fri, 19 Sep 2014 03:48:02 +0000
Received: (at 18491) by debbugs.gnu.org; 19 Sep 2014 03:47:47 +0000
Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XUpAg-0005l8-Sb
	for submit <at> debbugs.gnu.org; Thu, 18 Sep 2014 23:47:47 -0400
Received: from smtp1.cc.ic.ac.uk ([155.198.5.155]:46741)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XUpAe-0005ku-6j
 for 18491 <at> debbugs.gnu.org; Thu, 18 Sep 2014 23:47:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=imperial.ac.uk; s=main01; 
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From;
 bh=MgZ8ptf4cL3PSibsLGoBn6H1RgaFjB3A5oIV56nF3VA=; 
 b=Sr/hqF20gvElA+PEGMA6N0nzaO8NMZpaz4WOI3GCe+sCZN4w/G8TAoFT/35ZvTAMRcHbEJhyWqX+2GMLnw3fDSdlC/sKJKxSn3zZ/I3/WwmXP/k/2DLrtBHh+SskIgfyVDryy/FZmWRFixiQ8N9OoaG/SF/wsBIWiMjwoS++yxw=;
Received: from [176.251.158.159] (helo=localhost)
 by smtp1.cc.ic.ac.uk with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128)
 (Exim 4.82.1) (envelope-from <gian.ntzik08@HIDDEN>)
 id 1XUpAY-0007Hx-Jy; Fri, 19 Sep 2014 04:47:40 +0100
From: Gian Ntzik <gian.ntzik08@HIDDEN>
References: <87sijqbybz.fsf@HIDDEN>
 <20140918151521298129111@HIDDEN>
 <474d79845d2d4c2cb1a711d09ecb7de9@HIDDEN>
Date: Fri, 19 Sep 2014 04:47:38 +0100
In-Reply-To: <474d79845d2d4c2cb1a711d09ecb7de9@HIDDEN> (Linda
 A. Walsh's message of "Thu, 18 Sep 2014 23:40:41 +0000")
Message-ID: <877g10b7ad.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IC-MsgID: 1XUpAY-0007Hx-Jy
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

"Linda A. Walsh" <coreutils@HIDDEN> writes:

> Bob Proulx wrote:
>> Gian Ntzik wrote:
>>> It seems that using rm -r with a path that goes into a (non-empty)
>>> directory intended for removal (and back up e.g. using dot-dots) fails
>>> to remove the directory. The directory is rendered empty, but itself not
>>> removed.
>>>
>>> For example,
>>>
>>> $ mkdir -p /tmp/a/b/c
>>> $ mkdir -p /tmp/a/e
>>> $ rm -r /tmp/a/b/../../a
>>> rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory
>>
>> Trying to do anything to work around this seems wrong to me since it
>> will require keeping track of the state before and simulating to
>> create the desired state afterward and then applying a derived state
>> change to the file system.  That is much too complex for this simple
>> operation.
> ----
>     One would think the same for rm -fr "foo/.", but the
> straight-forward application of the depth-first removal was
> removed from "rm" for special cases.  One would think
> that the underlying tree might be easily addressed:
>
> function rmr {
>   local rd=$(cd "$1"; /bin/pwd)
>   echo rm -r "$rd"
> }
>

Yes, this would work because getcwd() gives a canonical path (no dot-dot
or symlinks). Issues like the one reported do not arise with canonical paths.
Another simple way to address the issue could be:

if [ -d $1 ]
then
    rm -r "$(/bin/readlink -e $1)"
else
    rm -r "$1"
fi

which does not change the cwd.

(assume that sufficient on the argument ending in dot, dot-dot or being
/ are done beforehand).

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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