Since there is already an unlink command that corresponds to unlinking a file,
but there seems to be no command corresponding to the POSIX
remove command, it seems upgrading 'rm' to use the 'remove'
POSIX call would be a beneficial move of all the recent POSIX
changes.
So how about upgrading 'rm'
tag 15926 notabug
close 15926
stop
On 11/19/2013 11:56 AM, Linda Walsh wrote:
> Since there is already an unlink command that corresponds to unlinking a file,
> but there seems to be no command corresponding to the POSIX
> remove command, it seems upgrading 'rm' to use the 'remove'
> POSIX call wo
On 19/11/2013 04:15, Pádraig Brady wrote:
tag 15926 notabug
close 15926
stop
On 11/19/2013 11:56 AM, Linda Walsh wrote:
> Since there is already an unlink command that corresponds to unlinking a file,
> but there seems to be no command corresponding to the POSIX
> remove command, it seems upgr
On 11/19/2013 11:17 AM, Linda Walsh wrote:
>> Well we have the -d option to rm to explicitly do that.
> ---
> Does the posix "remove" call require a -d?
Huh? There is no POSIX remove(1), only remove(3), unlink(2), rmdir(2),
rm(1), rmdir(1), and unlink(1) (using the traditional notation of which
m
On 19/11/2013 10:34, Eric Blake wrote:
On 11/19/2013 11:17 AM, Linda Walsh wrote:
>> Well we have the -d option to rm to explicitly do that.
> ---
> Does the posix "remove" call require a -d?
Huh? There is no POSIX remove(1),
Since when do you think of a "call" as being a command?
Sorr
Linda Walsh wrote:
> but there seems to be no command corresponding to the POSIX
> remove command,
The language here is confusing. There isn't any "remove command".
There is only the remove(3) library call.
man 3 remove
> it seems upgrading 'rm' to use the 'remove' POSIX call would be a
> ben
On 19/11/2013 12:45, Bob Proulx wrote:
Since when do you think of a "call" as being a command?
We don't. But from what you wrote ("Does the posix "remove" call
require a -d?") makes it appear that you think the posix remove(3)
library call is a command. Because library calls do not take opt
On 11/19/2013 05:02 PM, Linda Walsh wrote:
> I'm not see what would break. instead of failing to remove a non-empty
> directory, it would remove it (if it was empty and permissions allowed).
That's what would break. Scripts have been written to assume that 'rm
empty_dir' will fail, and your pro
On 11/19/2013 01:45 PM, Bob Proulx wrote:
>> Posix changed that requiring special checks for ".". Scripts relied
>> on that behavior for 30-40 years as well... If you want to use that
>> reasoning, rm should go back to doing depth first deletion and
>> reporting an error with deleting "." when i
On 11/20/2013 03:19 AM, Eric Blake wrote:
> Yes, the 'rm -rf .' case appears to be a regression in coreutils that is
> contrary to the behavior required by POSIX. That is:
>
> $ mkdir /tmp/foo /tmp/foo/sub
> $ cd /tmp/foo
> $ rm -r .
> rm: cannot remove directory: ‘.’
> $ ls
> sub
>
> appears to
On 11/19/2013 11:45 PM, Bernhard Voelker wrote:
> On 11/20/2013 03:19 AM, Eric Blake wrote:
>> Yes, the 'rm -rf .' case appears to be a regression in coreutils that is
>> contrary to the behavior required by POSIX. That is:
>>
>> $ mkdir /tmp/foo /tmp/foo/sub
>> $ cd /tmp/foo
>> $ rm -r .
>> rm: c
On 11/20/2013 02:44 PM, Eric Blake wrote:
> On 11/19/2013 11:45 PM, Bernhard Voelker wrote:
>> Maybe "cannot remove directory" is a bit weak - it's more like
>> "refusing to remove dot|dot-dot|root directory".
>
> Indeed, a clearer error message would be possible.
What about the following?
$ s
On 20/11/2013 16:03, Bernhard Voelker wrote:
$ src/rm -r src/.
src/rm: refusing to remove '.' or '..' directory: skipping 'src/.'
That gets back to what Bob mentioned about it being a
nanny-restriction.
The inevitable comment to be asked by someone is
"Refuse?
Isn't it my compute
On 11/20/2013 05:03 PM, Bernhard Voelker wrote:
> On 11/20/2013 02:44 PM, Eric Blake wrote:
>> On 11/19/2013 11:45 PM, Bernhard Voelker wrote:
>>> Maybe "cannot remove directory" is a bit weak - it's more like
>>> "refusing to remove dot|dot-dot|root directory".
>>
>> Indeed, a clearer error messag
On 11/20/2013 05:48 PM, Linda Walsh wrote:
> I still think an ENV flag that lists the command
Environment variables that modify behavior are nasty, and should
generally be avoided when simpler solutions exist. In this case, I'd
much rather add a long option, 'rm --no-preserve-dot', and let you wr
On 11/21/2013 01:48 AM, Linda Walsh wrote:
> Isn't it my computer? How do I override such a refusal?
That riddle isn't too hard, is it? ;-)
POSIX (and common sense) forbids to remove something ending on ".".
Therefore just use the canonicalized name, e.g.:
$ mkdir /tmp/xx
$ cd /tmp/xx
On 11/21/2013 03:07 AM, Eric Blake wrote:
> On 11/20/2013 05:03 PM, Bernhard Voelker wrote:
>> What about the following?
>>
>> $ src/rm -r src/.
>> src/rm: refusing to remove '.' or '..' directory: skipping 'src/.'
>
> That helps.
Thanks, I'll push it unless someone comes up with a better wor
On 11/21/2013 12:03 AM, Bernhard Voelker wrote:
>if (dot_or_dotdot (last_component (ent->fts_accpath)))
> {
> - error (0, 0, _("cannot remove directory: %s"),
> - quote (ent->fts_path));
> + error (0, 0,
> +
On 11/21/2013 07:12 AM, Bernhard Voelker wrote:
> On 11/21/2013 03:07 AM, Eric Blake wrote:
>> On 11/20/2013 05:03 PM, Bernhard Voelker wrote:
>>> What about the following?
>>>
>>> $ src/rm -r src/.
>>> src/rm: refusing to remove '.' or '..' directory: skipping 'src/.'
>>
>> That helps.
>
> Th
On 20/11/2013 22:32, Bernhard Voelker wrote:
On 11/21/2013 01:48 AM, Linda Walsh wrote:
Isn't it my computer? How do I override such a refusal?
$ rm -rv "$(pwd -P)"
removed directory: ‘/tmp/xx’
--
That doesn't give the same behavior and isn't what I want.
Compare to "cp".
Say I wa
On 11/21/2013 09:54 AM, Pádraig Brady wrote:
On 11/21/2013 12:03 AM, Bernhard Voelker wrote:
if (dot_or_dotdot (last_component (ent->fts_accpath)))
{
- error (0, 0, _("cannot remove directory: %s"),
- quote (ent->fts_path));
+
On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
>
> Admittedly, compared to the academic question behind "--no-preserve-root"
> (which is like "what happens to me when the globe under my feet disappears?"),
> there may be more real-world reasons to remove ".".
But that's not what Linda is asking
On 11/21/2013 10:50 AM, Bob Proulx wrote:
>>> Could you explain why rm would get this and say chmod would not?
>
> Argh! Feature creep!
Maybe, but it certainly seems like a useful feature.
>
> The reason that rm should have it but chmod should not is that it is
> to work around the POSIX nann
On 11/21/2013 10:38 AM, Eric Blake wrote:
> On 11/21/2013 10:35 AM, Pádraig Brady wrote:
>> as I don't see it as specific to rm.
>> I.E. other tools like chmod etc would have the same requirement,
>> and they might be handled with various shell globbing constructs.
>> Even more generally find(1) co
On 11/21/2013 10:18 AM, Bob Proulx wrote:
>
>> Instead, she wants a command that will recursively remove the
>> children of ".", but then leave "." itself unremoved (whether by
>> virtue of the fact that rmdir(".") must fail
>
> I am missing this part. Why must it fail? And in fact as per my te
On 11/21/2013 01:39 PM, Eric Blake wrote:
> On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
>
>>
>> Admittedly, compared to the academic question behind "--no-preserve-root"
>> (which is like "what happens to me when the globe under my feet
>> disappears?"),
>> there may be more real-world reason
On 21/11/2013 09:50, Bob Proulx wrote:
Eric Blake wrote:
P�draig Brady wrote:
as I don't see it as specific to rm.
I.E. other tools like chmod etc would have the same requirement,
and they might be handled with various shell globbing constructs.
Even more generally find(1) could be used to ha
On Wed, Nov 20, 2013 at 4:03 PM, Bernhard Voelker
wrote:
> On 11/20/2013 02:44 PM, Eric Blake wrote:
>> On 11/19/2013 11:45 PM, Bernhard Voelker wrote:
>>> Maybe "cannot remove directory" is a bit weak - it's more like
>>> "refusing to remove dot|dot-dot|root directory".
>>
>> Indeed, a clearer er
On 11/21/2013 09:18 AM, Bernhard Voelker wrote:
> On 11/21/2013 04:06 PM, Eric Blake wrote:
>> Hard to say that it is considerable bloat without seeing a patch; we
>> already know when the top-level arguments are directories thanks to
>> 'rm -d'.
>
> Here's a draft - not tested more than this:
>
On 11/21/2013 07:42 AM, Bernhard Voelker wrote:
> I'm not happy with the semantic as the difference to all other existing
> uses of rm(1) would be that the argument is explicitly not removed,
> but well, ...
Such is life - and that's why it requires a new long option.
>
> Such --children-only wo
On 11/21/2013 02:39 PM, Eric Blake wrote:
[...] Instead, she wants a command that will
recursively remove the children of ".", but then leave "." itself
unremoved (whether by virtue of the fact that rmdir(".") must fail and
so the overall rm command fails, or by explicitly skipping the attempt
to
Eric Blake wrote:
> Pádraig Brady wrote:
> > as I don't see it as specific to rm.
> > I.E. other tools like chmod etc would have the same requirement,
> > and they might be handled with various shell globbing constructs.
> > Even more generally find(1) could be used to handle arbitrarily
> > many f
On 21/11/2013 09:18, Bob Proulx wrote:
Eric Blake wrote:
But that's not what Linda is asking for. She is not asking to pull "."
out of under her feet.
Actually as I understand it she is expecting the call to succeed if
the system kernel allows it. I believe that is the way rm used to
work
On Thu, Nov 21, 2013 at 8:18 AM, Bernhard Voelker
wrote:
> On 11/21/2013 04:06 PM, Eric Blake wrote:
>>
>> Hard to say that it is considerable bloat without seeing a patch; we
>> already know when the top-level arguments are directories thanks to 'rm
>> -d'.
>
>
> Here's a draft - not tested more
On 11/19/2013 05:15 AM, Pádraig Brady wrote:
>> So how about upgrading 'rm' to use the remove function so
>> it would work on empty directories as well.
>
> Well we have the -d option to rm to explicitly do that.
> That's a fairly fundamental change that would have backwards compat issues.
> POSIX
On 11/21/2013 11:01 AM, Pádraig Brady wrote:
> I'm not sure it's useful enough functionality to expose,
> and personally I'd use something like:
>
> children() { find "$1" -maxdepth 1 -mindepth 1; }
> or
> children() { find "$1" | sed '1d'; }
>
> and then...
>
> children $dir | xargs rm -r
Exc
On 11/21/2013 09:34 AM, Bernhard Voelker wrote:
> On 11/21/2013 05:25 PM, Eric Blake wrote:
>> On 11/21/2013 09:18 AM, Bernhard Voelker wrote:
>>> + /* If true (and the -r option is also specified), remove all children
>>> + of directory arguments, yet retaining the directory itself. */
>>> +
On 11/21/2013 05:39 PM, Eric Blake wrote:
> On 11/21/2013 10:38 AM, Eric Blake wrote:
>> On 11/21/2013 10:35 AM, Pádraig Brady wrote:
>>> as I don't see it as specific to rm.
>>> I.E. other tools like chmod etc would have the same requirement,
>>> and they might be handled with various shell globbi
On 11/21/2013 05:25 PM, Eric Blake wrote:
On 11/21/2013 09:18 AM, Bernhard Voelker wrote:
+ /* If true (and the -r option is also specified), remove all children
+ of directory arguments, yet retaining the directory itself. */
+ bool children_only;
Should --children-only imply -r, rathe
On 11/21/2013 04:06 PM, Eric Blake wrote:
Hard to say that it is considerable bloat without seeing a patch; we
already know when the top-level arguments are directories thanks to 'rm -d'.
Here's a draft - not tested more than this:
$ mkdir -p /tmp/dir /tmp/dir/sub
$ touch /tmp/dir/file /tm
On Thu, Nov 21, 2013 at 5:39 AM, Eric Blake wrote:
> On 11/21/2013 12:12 AM, Bernhard Voelker wrote:
...
> But that's not what Linda is asking for. She is not asking to pull "."
> out of under her feet. Instead, she wants a command that will
> recursively remove the children of ".", but then lea
Eric Blake wrote:
> But that's not what Linda is asking for. She is not asking to pull "."
> out of under her feet.
Actually as I understand it she is expecting the call to succeed if
the system kernel allows it. I believe that is the way rm used to
work before removing '.' was disallowed.
mk
On 11/21/2013 10:35 AM, Pádraig Brady wrote:
> as I don't see it as specific to rm.
> I.E. other tools like chmod etc would have the same requirement,
> and they might be handled with various shell globbing constructs.
> Even more generally find(1) could be used to handle arbitrarily
> many files a
On 11/23/2013 02:30 AM, Pádraig Brady wrote:
> On 11/23/2013 01:02 AM, Bernhard Voelker wrote:
>> >From a87e3d0a8417648e65ee077ca6f70d5d19fa757a Mon Sep 17 00:00:00 2001
>> From: Bernhard Voelker
>> Date: Sat, 23 Nov 2013 01:55:36 +0100
>> Subject: [PATCH] tests: add a test for rm -rf "/"
Hi Padr
On 11/25/2013 12:15 AM, Bernhard Voelker wrote:
> On 11/23/2013 02:30 AM, Pádraig Brady wrote:
>> On 11/23/2013 01:02 AM, Bernhard Voelker wrote:
>>> >From a87e3d0a8417648e65ee077ca6f70d5d19fa757a Mon Sep 17 00:00:00 2001
>>> From: Bernhard Voelker
>>> Date: Sat, 23 Nov 2013 01:55:36 +0100
>>> Sub
On 11/25/2013 02:10 AM, Pádraig Brady wrote:
> On 11/25/2013 12:15 AM, Bernhard Voelker wrote:
>> +cat > k.c <<'EOF' || framework_failure_
>> +#include
>> +#include
>> +#include
>> +
>> +int unlinkat (int dirfd, const char *pathname, int flags)
>> +{
>> + /* Prove that LD_PRELOAD works: create
On 11/25/2013 08:31 AM, Bernhard Voelker wrote:
> On 11/25/2013 02:10 AM, Pádraig Brady wrote:
>> So this might race with rm being preempted between the touch() and the
>> exit(),
>> causing a false failure? It's probably best to not kill if the 'x' file
>> exists,
>> as it's very unlikely that r
On 11/26/2013 11:08 PM, Bernhard Voelker wrote:
> +#---
> +# Exercise "rm -r /" without and with the --preserve-root option.
> +# Also exercise the synonyms '///' and '' which would normally go into
> +# the 'synonyms'
On 11/27/2013 04:14 AM, Pádraig Brady wrote:
> On 11/26/2013 11:08 PM, Bernhard Voelker wrote:
>> +#---
>> +# Exercise "rm -r /" without and with the --preserve-root option.
>> +# Also exercise the synonyms '///' and ''
On 11/28/2013 12:14 AM, Bernhard Voelker wrote:
> On 11/27/2013 04:14 AM, Pádraig Brady wrote:
>> On 11/26/2013 11:08 PM, Bernhard Voelker wrote:
>>> +#---
>>> +# Exercise "rm -r /" without and with the --preserve-root opti
On 11/29/2013 02:43 AM, Pádraig Brady wrote:
> It all looks good [...]
Thanks for the review(s)!
> [...] apart from the `timeout 2` race.
> Unlikely but not something we could release on a bazillion
> build hosts doing `make check`.
> So as a compromise how about disabling the test by default by
Eric Blake wrote:
> Bernhard Voelker wrote:
> > Bob Proulx wrote:
> > +# Exercise "rm -rf /" without the --preserve-root and --no-preserve-root
> > option.
> > +# Expect a non-Zero exist status.
> > +exercise_rm_rf_root \
> > + && fail=1
>
> Maybe you should favor 'rm -r /' rather than 'rm -rf /
On 11/29/2013 07:57 PM, Bob Proulx wrote:
> Eric Blake wrote:
>> Bernhard Voelker wrote:
>>> Bob Proulx wrote:
>>> +# Exercise "rm -rf /" without the --preserve-root and --no-preserve-root
>>> option.
>>> +# Expect a non-Zero exist status.
>>> +exercise_rm_rf_root \
>>> + && fail=1
>>
>> Maybe yo
On 11/29/2013 06:48 PM, Pádraig Brady wrote:
> To summarize, it,
> only runs with: make EXPENSIVE=yes check,
> only runs as non root,
> ensures file & dir removal bypass work in a safe context first
>
> Do you still think it's too dangerous?
I think we've done a great job at writing a very robus
Pádraig Brady wrote:
> Bob Proulx wrote:
> > I still think this is a very scary test and isn't worth the return on
> > investment. It is the kind of thing that makes me think I could never
> > recommend building coreutils anywhere but in a throwaway chroot.
> > Because the risk of a failure is jus
On 11/30/2013 10:33 PM, Bob Proulx wrote:
> [...] I still think that
> was way too much investment for the potential return.
I wouldn't say that: 20 of the 21 runs of "rm -r /" prove that
'rm' skips the '/' argument and various synonyms, as required
by POSIX (and common sense). I think it's impo
On 11/30/2013 02:33 PM, Bob Proulx wrote:
> But for example what happens if the preferred unlink command ever
> changes from unlinkat() to something new about ten years in the
> future? Can't say it won't change since we have already seen it
> change.
Indeed, we've already moved from unlink()/rmd
close 15926
stop
(triaging old bugs)
The original topic of using remove(2) call in rm(1)
was decided to be undesirable.
Starting at around the 33rd message [1] the thread diverges into bugs in
"rm -rf ." and similar problems (which are resolved by the 221st
message [2].
[1] https://bugs.gnu.or
58 matches
Mail list logo
