GNU bug report logs - #18491
rm -r fails to delete entire hierarchy when path goes in and out of it

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: coreutils; Reported by: Gian Ntzik <gian.ntzik08@HIDDEN>; dated Wed, 17 Sep 2014 19:42:02 UTC; Maintainer for coreutils is bug-coreutils@HIDDEN.

Message received at 18491 <at> debbugs.gnu.org:


Received: (at 18491) by debbugs.gnu.org; 19 Sep 2014 03:47:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 18 23:47:47 2014
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>
To: "Linda A. Walsh" <coreutils@HIDDEN>
Subject: Re: bug#18491: rm -r fails to delete entire hierarchy when path goes
 in and out of it
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-Debbugs-Envelope-To: 18491
Cc: "18491 <at> debbugs.gnu.org" <18491 <at> debbugs.gnu.org>,
 Bob Proulx <bob@HIDDEN>
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). 




Information forwarded to bug-coreutils@HIDDEN:
bug#18491; Package coreutils. Full text available.

Message received at 18491 <at> debbugs.gnu.org:


Received: (at 18491) by debbugs.gnu.org; 19 Sep 2014 03:30:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 18 23:30:38 2014
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>
To: Bob Proulx <bob@HIDDEN>
Subject: Re: bug#18491: rm -r fails to delete entire hierarchy when path goes
 in and out of it
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-Debbugs-Envelope-To: 18491
Cc: "18491 <at> debbugs.gnu.org" <18491 <at> debbugs.gnu.org>
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.





Information forwarded to bug-coreutils@HIDDEN:
bug#18491; Package coreutils. Full text available.

Message received at 18491 <at> debbugs.gnu.org:


Received: (at 18491) by debbugs.gnu.org; 18 Sep 2014 23:41:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 18 19:41:43 2014
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
To: Bob Proulx <bob@HIDDEN>
Subject: Re: bug#18491: rm -r fails to delete entire hierarchy when path goes
 in	and out of it
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-Debbugs-Envelope-To: 18491
Cc: Gian Ntzik <gian.ntzik08@HIDDEN>, 18491 <at> debbugs.gnu.org
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.  :-|










Information forwarded to bug-coreutils@HIDDEN:
bug#18491; Package coreutils. Full text available.

Message received at 18491 <at> debbugs.gnu.org:


Received: (at 18491) by debbugs.gnu.org; 18 Sep 2014 21:28:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 18 17:28:06 2014
Received: from localhost ([127.0.0.1]:44852 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XUjFF-0007cZ-Pc
	for submit <at> debbugs.gnu.org; Thu, 18 Sep 2014 17:28:06 -0400
Received: from joseki.proulx.com ([216.17.153.58]:37029)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <bob@HIDDEN>) id 1XUjFD-0007cQ-3k
 for 18491 <at> debbugs.gnu.org; Thu, 18 Sep 2014 17:28:04 -0400
Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119])
 by joseki.proulx.com (Postfix) with ESMTP id B880A218C2;
 Thu, 18 Sep 2014 15:28:01 -0600 (MDT)
Received: by hysteria.proulx.com (Postfix, from userid 1000)
 id 7C59E2DC39; Thu, 18 Sep 2014 15:28:01 -0600 (MDT)
Date: Thu, 18 Sep 2014 15:28:01 -0600
From: Bob Proulx <bob@HIDDEN>
To: Gian Ntzik <gian.ntzik08@HIDDEN>
Subject: Re: bug#18491: rm -r fails to delete entire hierarchy when path goes
 in and out of it
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)
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 18491
Cc: 18491 <at> debbugs.gnu.org
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 (/)

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




Information forwarded to bug-coreutils@HIDDEN:
bug#18491; Package coreutils. Full text available.

Message received at 18491 <at> debbugs.gnu.org:


Received: (at 18491) by debbugs.gnu.org; 17 Sep 2014 20:08:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 17 16:08:27 2014
Received: from localhost ([127.0.0.1]:43631 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XULWd-0006tW-8S
	for submit <at> debbugs.gnu.org; Wed, 17 Sep 2014 16:08:27 -0400
Received: from smtp.cs.ucla.edu ([131.179.128.62]:43204)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eggert@HIDDEN>) id 1XULWa-0006tO-H4
 for 18491 <at> debbugs.gnu.org; Wed, 17 Sep 2014 16:08:25 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
 by smtp.cs.ucla.edu (Postfix) with ESMTP id CDBAC39E801B;
 Wed, 17 Sep 2014 13:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1])
 by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id isz4YOUmKKIP; Wed, 17 Sep 2014 13:08:15 -0700 (PDT)
Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200])
 by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3673039E8015;
 Wed, 17 Sep 2014 13:08:15 -0700 (PDT)
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
To: Gian Ntzik <gian.ntzik08@HIDDEN>, 18491 <at> debbugs.gnu.org
Subject: Re: bug#18491: rm -r fails to delete entire hierarchy when path goes
 in and out of it
References: <87sijqbybz.fsf@HIDDEN>
In-Reply-To: <87sijqbybz.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 18491
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: -3.0 (---)

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.




Information forwarded to bug-coreutils@HIDDEN:
bug#18491; Package coreutils. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 17 Sep 2014 19:41:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 17 15:41:32 2014
Received: from localhost ([127.0.0.1]:43604 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XUL6Z-00069f-Ew
	for submit <at> debbugs.gnu.org; Wed, 17 Sep 2014 15:41:32 -0400
Received: from eggs.gnu.org ([208.118.235.92]:39542)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XU7xe-0000ZX-Q1
 for submit <at> debbugs.gnu.org; Wed, 17 Sep 2014 01:39:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XU7xX-0002sC-Me
 for submit <at> debbugs.gnu.org; Wed, 17 Sep 2014 01:39:26 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:46664)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XU7xX-0002rg-Iu
 for submit <at> debbugs.gnu.org; Wed, 17 Sep 2014 01:39:19 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41233)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XU7xO-0001DM-L4
 for bug-coreutils@HIDDEN; Wed, 17 Sep 2014 01:39:16 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XU7xI-0002lx-Ny
 for bug-coreutils@HIDDEN; Wed, 17 Sep 2014 01:39:10 -0400
Received: from smtp1.cc.ic.ac.uk ([155.198.5.155]:33638)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <gian.ntzik08@HIDDEN>) id 1XU7xI-0002du-Hg
 for bug-coreutils@HIDDEN; Wed, 17 Sep 2014 01:39:04 -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:Date:Subject:To:From;
 bh=DTGefWNXPV2fdGmbpvAteO9BKqZVtWkuP+uAtzEV3rg=; 
 b=pR8S02fgRvtWWrBPzazkdkqN1gboZdXWp+CHTVGNLkhP9vmOChzSqekTHhmCcNk6g70AGIigzrzA7b1fPakL1BgN32yDUDZX6sqMPPezRC74RbrbVESlobZstaFLSlkWMYtKWl6JkmWYEjJwTxn3l4AMj0YJCxEGYD7T7DU0JGM=;
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 1XU7xB-0007jJ-6I
 for bug-coreutils@HIDDEN; Wed, 17 Sep 2014 06:38:57 +0100
From: Gian Ntzik <gian.ntzik08@HIDDEN>
To: bug-coreutils@HIDDEN
Subject: rm -r fails to delete entire hierarchy when path goes in and out of it
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
X-IC-MsgID: 1XU7xB-0007jJ-6I
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 208.118.235.17
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Wed, 17 Sep 2014 15:41:28 -0400
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: -4.0 (----)


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




Acknowledgement sent to Gian Ntzik <gian.ntzik08@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-coreutils@HIDDEN. Full text available.
Report forwarded to bug-coreutils@HIDDEN:
bug#18491; Package coreutils. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

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