GNU bug report logs -
#12400
rmdir: add --one-file-system option
Previous Next
Reported by: Linda Walsh <coreutils <at> tlinx.org>
Date: Mon, 10 Sep 2012 00:32:01 UTC
Severity: wishlist
Tags: wontfix
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12400 in the body.
You can then email your comments to 12400 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 00:32:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Linda Walsh <coreutils <at> tlinx.org>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Mon, 10 Sep 2012 00:32:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
If you are going to only provide 1 mode of functionality, it should
be to only rmdir dirs on the same file system as the starting args.
Instead it follows network mount points doing who knows what. I
already know that it has in the past, on network'd file systems, gone
ahead and did a 'pre-delete' on a dir that read as 'unwritable' due to
files being in the dir -- and renamed it to some obscure name for later
processing when it thought it would make a difference. While that problem
was fixed, it was caused by a change in the linux-based netword-file-share
software.
Having rmdir follow all network mounts and deleting remote files would seem
to be a nasty potential security issue.
Note, using shell to do this, is the normal recommended way to do this,
just like rm I'm told, is the recommended solution, so
following those instructions, I tried to use "rmdir **", (since rmdir has
no recursive option, it is mandatory to use shell.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 01:06:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Shouldn't that be 'users "curse" rmdir'?
All rmdir implementations behave that way;
GNU rmdir is no different.
It's not clear to me why 'rmdir /foo/a /bar/b' should by default
reject the attempt to remove '/bar/b' merely because it's on a
different file system from '/foo/a'.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 01:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Shouldn't that be 'users "curse" rmdir'?
>
> All rmdir implementations behave that way;
> GNU rmdir is no different.
>
> It's not clear to me why 'rmdir /foo/a /bar/b' should by default
> reject the attempt to remove '/bar/b' merely because it's on a
> different file system from '/foo/a'.
----
Then why have the option for 'rm'?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 01:55:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 12400 <at> debbugs.gnu.org (full text, mbox):
On 09/09/2012 06:40 PM, Linda Walsh wrote:
>> It's not clear to me why 'rmdir /foo/a /bar/b' should by default
>> reject the attempt to remove '/bar/b' merely because it's on a
>> different file system from '/foo/a'.
> ----
> Then why have the option for 'rm'?
There is no such option for 'rm'. The --one-file-system
option is a different option; it doesn't have the behavior
mentioned above.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 03:39:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> On 09/09/2012 06:40 PM, Linda Walsh wrote:
>>> It's not clear to me why 'rmdir /foo/a /bar/b' should by default
>>> reject the attempt to remove '/bar/b' merely because it's on a
>>> different file system from '/foo/a'.
>> ----
>> Then why have the option for 'rm'?
>
> There is no such option for 'rm'. The --one-file-system
> option is a different option; it doesn't have the behavior
> mentioned above.
Right...but I'm not using the behavior described above, I'm
using the wildcard option rm **
In the same way...ahhh....so when I asked for code for rm -fr . I didn't
included the code:
Priv->run([$Rm, "--one-file-system", "-fr", "."]);
rm -rf * .[!.] .??*
If I understand you correctly, rm --one-file-system -fr * .[1.] .??* isn't
going to stay on one file system.
So is that a bug in rm or in shell?
or how do I remove all the files in /tmp, but not have it descend into any file
systems mounted in tmp?
Cuz if rmdir using wildcards won't work with --one-file-system, I'm
guessing it won't work in 'rm' either.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 05:16:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Linda Walsh wrote:
> or how do I remove all the files in /tmp, but not have it descend
> into any file systems mounted in tmp?
I think it is really problematic to mount filesystems under /tmp.
That would be a really crazy situation. I wouldn't do it.
But...
find /tmp -xdev -mindepth 1 -delete
-xdev Don't descend directories on other filesystems.
The -mindepth 1 prevents it from matching /tmp itself.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 05:24:01 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
Linda Walsh wrote:
> If you are going to only provide 1 mode of functionality, it should
> be to only rmdir dirs on the same file system as the starting args.
But rmdir really only removes the directories you tell it. What is
the command you are complaining about? Are you using --parents or
something?
> Instead it follows network mount points doing who knows what.
Doing rmdir?
> I already know that it has in the past, on network'd file systems,
> gone ahead and did a 'pre-delete' on a dir that read as 'unwritable'
> due to files being in the dir -- and renamed it to some obscure name
> for later processing when it thought it would make a difference.
You are probably talking about the nfs last close problem. NFS
renames files to a .nfsXYZ where XYZ is a unique random string. If it
were a local stateful filesystem it would be able to implement this
correctly. But for a remote networked filesystem it can only be
emulated by doing thins like renaming. Search for nfs last close
problem and you will see the issue.
> Having rmdir follow all network mounts and deleting remote files would seem
> to be a nasty potential security issue.
But rmdir only removes the directories you tell it to remove.
> Note, using shell to do this, is the normal recommended way to do this,
> just like rm I'm told, is the recommended solution, so
> following those instructions, I tried to use "rmdir **", (since rmdir has
> no recursive option, it is mandatory to use shell.
There are two pieces there. One is that the shell, if it is one of
the magic shells that supports **, will expand that into an explicit
list of option arguments for the rmdir command. The other is the
rmdir command which will simply get a list of option arguments. By
doing it that way there is no way for rm to know that they are
anything other than explicitly named directories to be removed.
If you want a recursive option why not use 'rm -rf'?
There is always 'find' with the -delete option. But regardless there
has been the find -exec option.
find /some/path -type d -delete
find /some/path -depth -type d -exec rmdir {} +
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 05:26:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 12400 <at> debbugs.gnu.org (full text, mbox):
On 09/09/2012 08:37 PM, Linda Walsh wrote:
> I'm using the wildcard option rm **
Then why is this bug report about rmdir?
I'm afraid that your bug report was incoherent,
as was your followup.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 05:51:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> On 09/09/2012 08:37 PM, Linda Walsh wrote:
>> I'm using the wildcard option rm **
>
> Then why is this bug report about rmdir?
Because it was rmdir that chased off to network FS's when I
used wildcard syntax with it as I was told to do with rm.
This is why I didn't want to use shell. I knew something
would go wrong, now I should use find .. how many work-arounds
for the bugs in rm are you going to suggest?
If the workaround for rm to remove all files doesn't work with
--one-file-system, then it's not a workaround.
As for rmdir, I usually do use 'find' when I want to do what I did,
but having been told that doing so wasn't safe, on another list as they'd
had it fail (as I did -- it tried to remove a dir with files in it -- something
I hadn't expected to ever happen, but due to a change in the Samba, and how
it responded to some network request, the OS promptly tried to rename what
it thought was a locked file into .<guidhexname>... It was only because I was
editing
a file in it at the time that I caught it at all and figured out what happened.
Between that, and being told to use shell wildcards to remove everything
under a mount point, I, naturally, thought to use it with rmdir. Not realizing
that I needed that --one-file-system to be there for that to work which
rmdir doesn't need as it doesn't expect to be used recursively.
Which points back at at the bad idea it is to use wildcards to get around
broken functionality.
rm ** removes all the files under a dir, and rmdir ** removes all the empty
directories
under a dir. It was the natural progression of avoiding a crippled feature in rm...
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 06:07:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Linda Walsh writes:
>
> rm ** removes all the files under a dir, and rmdir ** removes all the empty
> directories
> under a dir. It was the natural progression of avoiding a crippled feature in rm...
>
For someone who claims to have been unix for so long that you consider 4.3BSD
a recent deviation from the norm, you are awfully clueless about how
everything works. Or pretending to be so as a way of escalating the drama.
And the problem you won't quit bugging everyone about is hardly a problem
anyway; how often does the "remove everything under this directory, but not
crossing mount points, and not removing this directory itself" operation
actually prove necessary?
What you're doing is *weird* and there's no reason to *expect* it to be a
less-than-10-character command. It's still a one-liner with find, as you've
already been shown.
Unix deliberately presents a single unified filesystem namespace in which
mount points look like normal directories. Recursion that traverses all
directories except mount points is *weird*.
And mounting something under /tmp that isn't logically part of /tmp (and
subject to the same cleanup policy) is *very weird*.
Please stop filing bug reports resulting from your own weirdness.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 07:30:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Alan Curry wrote:
> Linda Walsh writes:
>> rm ** removes all the files under a dir, and rmdir ** removes all the empty
>> directories
>> under a dir. It was the natural progression of avoiding a crippled feature in rm...
>>
>
> For someone who claims to have been unix for so long that you consider 4.3BSD
> a recent deviation from the norm, you are awfully clueless about how
> everything works. Or pretending to be so as a way of escalating the drama.
---
Sorry, the version of rm i've used honored the '-f' flag...
Playing mommy to users -- that's what you'd expect from a university version
of unix.
You call programs that play mommy the norm?
>
> And the problem you won't quit bugging everyone about is hardly a problem
> anyway; how often does the "remove everything under this directory, but not
> crossing mount points, and not removing this directory itself" operation
> actually prove necessary?
----
Things can be easily mounted and cross mounted under linux. But
I didn't wanto to rm everything, I was using rmdir to remove empty directories.
I tried to use rmdir in a recusive form like the only supported recursive
version of rm -- one that uses wildcards.
You can't play mommie with 'rm' and expect people not to use such behaviors with
other commands. If you are going to treat people like children to protect them
from themselves, then don't be surprised when they blame you for your
inadequacies. You can't have it both ways -- the moral superiority of thinking
you are protecting people, yet the complete irresponsibility when the consequences
of teaching unthinking ways comes back to haunt you.
>
> What you're doing is *weird* and there's no reason to *expect* it to be a
> less-than-10-character command. It's still a one-liner with find, as you've
> already been shown.
I regularly clean out directories. It's rare that I will have mounted something
there. But I've had the rm follow links it didn't understand on other OS's that
were
not unix, but tried to be posix compatible -- and follow them into a recycle
bin, where it
found pointers to a whole bunch of places on the file system.
>
> Unix deliberately presents a single unified filesystem namespace in which
> mount points look like normal directories. Recursion that traverses all
> directories except mount points is *weird*.
----
Is that why almost all unix command have options to prevent them
from doing just that... and not it is not weird. Only under BSD is it weird, but
elsewhere, people mount things all over the place.
People are being encouraged in some circles to use mounts over a softlink --
> And mounting something under /tmp that isn't logically part of /tmp (and
> subject to the same cleanup policy) is *very weird*.
---
I don't have anything mounted under my /tmp, but I could easily see a
dir there being used as a scratch dir or a place to mount a scratch volume
temporarily.
If someone runs a program that does such a delete using BSD crippled utils
that cause bad behaviors, telling them they are weird as a response is perfect for
someone who thinks the world revolves around them and anyone who does anything
differently
is 'weird'....
That's really special.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 07:41:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Linda Walsh writes:
>
> Sorry, the version of rm i've used honored the '-f' flag...
> Playing mommy to users -- that's what you'd expect from a university version
> of unix.
The people with @gnu.org addresses may be inhibited from telling you to
shut up. So I'm telling you, please shut up. You're not a constructive
contributor in any way. You're just an incompetent user who thinks that every
time you do something stupid, it must be someone else's fault for not
designing the world around your stupidity.
If you'd posted a description of your problem on a *help* forum, you'd get
suggestions on how to solve it correctly. But you don't want to admit that
you need help, you'd rather to clutter up the bug tracker with whining
messages your failed attempts to solve your problem based on your supposed
knowledge of dead Unix variants from bankrupt companies.
Shut up.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 10 Sep 2012 10:50:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 12400 <at> debbugs.gnu.org (full text, mbox):
Alan Curry wrote:
> Linda Walsh writes:
>> Sorry, the version of rm i've used honored the '-f' flag...
>> Playing mommy to users -- that's what you'd expect from a university version
>> of unix.
>
> The people with @gnu.org addresses may be inhibited from telling you to
> shut up. So I'm telling you, please shut up. You're not a constructive
> contributor in any way.
----
That's because of obstructive know-it-all people like you who think
anyone who is not like you is wierd and has a problem.
> You're just an incompetent user who thinks that every
> time you do something stupid, it must be someone else's fault for not
> designing the world around your stupidity.
----
This only makes it obvious you didn't win anything -- you can't argue
against my points based on engineering grounds -- it is only because
you must obey your corporate masters that you resort to personal attacks
on the messenger.
> If you'd posted a description of your problem on a *help* forum, you'd get
> suggestions on how to solve it correctly. But you don't want to admit that
> you need help, you'd rather to clutter up the bug tracker with whining
> messages your failed attempts to solve your problem based on your supposed
> knowledge of dead Unix variants from bankrupt companies.
===
Every one of those dead variants died after going POSIX. Now I see
GNU going that way. Do the math.
You seem to think I have a problem other than what I stated. I need
a remove utility that does what rm is advertised to do without the special case
POSIX requirement(s?).
I'd like a utility that had intelligence, but that would be way over
your head.
Why shouldn't "rm dir/" remove an empty directory? Why shouldn't
-f, do what it means -- ignore errors and delete what it can? Why shouldn't
rm use rm "dir/." do something useful, safely -- why do you insist on it
doing nothing more than flaunting it's inability to do anything useful?
When I point out that I want to remove all files under
a directory AND stay on a file system -- then you call me weird -- because
you have no solution. It can't be done with 'rm'. You claim it is weird?
why have "--one-file-system if the command is SUPPOSED to traverse network
file systems?
you keep making statements like you know something about all users
and if they come up with a case that doesn't fit into your narrow predefined
world view, it's they who have the problem. Software is supposed to empower
users -- not be used to abuse them -- your use of software is screw users
and push how right you are and how much of a winner you are -- by putting
them down. If they want to constructively add to a command, they are not
allowed because it is required that certain features not be allowed by something
that is supposed to be a compatibility guideline of what to provide to support
compliant programs -- it's not supposed to be about what NOT to provide...
It was a list describing a minimal feature set -- NOT a maximal
or limiting feature set.
You want me to shutup? Then get out of the way and stop
hogging the pot, cause people like you block everyone else from making
anything better.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Fri, 18 Jan 2019 08:33:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 12400 <at> debbugs.gnu.org (full text, mbox):
retitle 12400 rmdir: add --one-file-system option
severity 12400 wishlist
tags 12400 wontfix
stop
(triaging old bugs)
Hello,
On 2012-09-09 11:22 p.m., Bob Proulx wrote:
> Linda Walsh wrote:
>> If you are going to only provide 1 mode of functionality, it should
>> be to only rmdir dirs on the same file system as the starting args.
>
[...]
> But rmdir only removes the directories you tell it to remove.
>
[...]
> If you want a recursive option why not use 'rm -rf'?
>
> There is always 'find' with the -delete option. But regardless there
> has been the find -exec option.
>
> find /some/path -type d -delete
>
> find /some/path -depth -type d -exec rmdir {} +
>
With no further comments in 6 years, I'm closing this
request.
regards,
- assaf
Changed bug title to 'rmdir: add --one-file-system option' from 'rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...'
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 18 Jan 2019 08:33:03 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'normal'
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 18 Jan 2019 08:33:03 GMT)
Full text and
rfc822 format available.
Added tag(s) wontfix.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 18 Jan 2019 08:33:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
12400 <at> debbugs.gnu.org and Linda Walsh <coreutils <at> tlinx.org>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 18 Jan 2019 10:53:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Wed, 06 Feb 2019 00:00:01 GMT)
Full text and
rfc822 format available.
Message #55 received at submit <at> debbugs.gnu.org (full text, mbox):
On 1/18/2019 12:32 AM, Assaf Gordon wrote:
> retitle 12400 rmdir: add --one-file-system option
> severity 12400 wishlist
> tags 12400 wontfix
> stop
>
>> If you want a recursive option why not use 'rm -rf'?
>>
-----
rmdir already provides a recursive delete that can cross
file system boundaries
dir1->dir2->dir3
dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another.
>> There is always 'find' with the -delete option. But regardless there
>> has been the find -exec option.
>>
----
true -- so why should 'rm' protect against crossing boundaries
deleting '/' or everything under '.' when there is find?
find is the obvious solution you are saying, so all that checking in
rm should be removed, as it is inconsistent with rmdir that can
cross boundaries.
As for closing something not addressed for 6 years while the problem
has grown worse -- (rmdir didnt' used to have a recursive delete), doesn't
seem a great way to judge whether or not a bug is valid or not .
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Sun, 10 Feb 2019 21:53:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 12400 <at> debbugs.gnu.org (full text, mbox):
L A Walsh wrote:
> >> If you want a recursive option why not use 'rm -rf'?
>
> rmdir already provides a recursive delete that can cross
> file system boundaries
Please provide an example. Something small. Something concrete.
Please include the version of rmdir.
Something like:
mkdir testdir testdir/dir1 testdir/dir2 testdir/dir2/dir3
rmdir --recursive testdir/dir2
rmdir --version
Include all input and output verbatim. For clarity do not use shell
file glob wildcards because that is a dependence upon a specific
command line shell and the shell's configuration.
> dir1->dir2->dir3
>
> dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another.
GNU Coreutils rmdir does not provide a recursive delete option.
Therefore one can only assume that the rmdir you are referring to is a
different rmdir from a different project.
I specifically asked if you were using the rmdir --parents option but
my message was the only mention of --parents in this entire ticket and
in subsequent responses your messages also did not mention it.
Therefore I can only assume that there is no --parents option being
used here.
> >> There is always 'find' with the -delete option. But regardless there
> >> has been the find -exec option.
>
> true -- so why should 'rm' protect against crossing boundaries
> deleting '/' or everything under '.' when there is find?
>
> find is the obvious solution you are saying, so all that checking in
> rm should be removed, as it is inconsistent with rmdir that can
> cross boundaries.
My mention of 'find' was really a simple statement about alternatives
when programmatic needs are desired. Because 'find' is the swiss army
chainsaw for directory traversal. I didn't mean to derail the
discussion there. But if it is to be derailed then 'find' is the best
choice when needing a specific set of programmatic requirements for
directory traversal. The other utilities that have simpler
capabilities are the distractions. But in theory this bug ticket was
about 'rmdir'.
> As for closing something not addressed for 6 years while the problem
> has grown worse -- (rmdir didnt' used to have a recursive delete), doesn't
> seem a great way to judge whether or not a bug is valid or not .
GNU Coreutils rmdir does not provide a recursive delete option.
This bug report so far has contained conflicting complaints to the
point that it has not been useful. It still is not clear if you are
complaining about 'rmdir' or 'rm' even after requests for
clarification. Or possibly your shell's ** file glob expansion.
Probably some combination of them all that is unique to your
environment.
To be useful a bug report must be descriptive so that the reader can
understand it. If the reader can't understand it then how can it be
useful? The report must be as simple as possible. Because extraneous
complexity is distracting. Stay focused on the bug being reported and
not about other unrelated things. Bugs about behavior should be
reproducible with a test case. Because nothing is as useful as a
concrete example.
I have reviewed the reports in this ticket and there seems to be no
viable bug report to operate upon here. At some point without a test
case it only makes sense to say enough is enough and move on since
this does not appear to be a bug in any program of the coreutils
project. However even though a bug is closed discussion may continue
as we are doing here. The bug state is simply a way to organize
reports for the purposes of triage. Many thanks to Assaf for putting
in the work to triage these old bug tickets.
If you wish to report a bug in rmdir's recursive delete option then we
must insist on a test case.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 11 Feb 2019 01:43:02 GMT)
Full text and
rfc822 format available.
Message #61 received at submit <at> debbugs.gnu.org (full text, mbox):
On 2/10/2019 1:52 PM, Bob Proulx wrote:
> L A Walsh wrote:
>>>> If you want a recursive option why not use 'rm -rf'?
>> rmdir already provides a recursive delete that can cross
>> file system boundaries
>
> Please provide an example. Something small. Something concrete.
> Please include the version of rmdir.
The original bug stems from having to use wild cards to delete
all files in a directory instead of '.', as in being told to use:
rm -fr --one-filesystem foo/*
instead of
rm -fr --one-filesystem foo/. or
cd foo && rm -fr --one-filesystem .
The recommended solution to use foo/* won't stay on 1 file
system, while an alternative using '.' would.
if I use rm --one-filesystem a b c, I could be deleting
files off of 3 file systems. Why would the argument be named
'one-filesystem' if there as no way to ensure that all files
were only on 1 file system?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Mon, 11 Feb 2019 10:58:01 GMT)
Full text and
rfc822 format available.
Message #64 received at submit <at> debbugs.gnu.org (full text, mbox):
On 2/10/2019 1:52 PM, Bob Proulx wrote:
> L A Walsh wrote:
>>>> If you want a recursive option why not use 'rm -rf'?
>> rmdir already provides a recursive delete that can cross
>> file system boundaries
>
> Please provide an example. Something small. Something concrete.
> Please include the version of rmdir.
----
As near as I can tell the rmdir case derives from
the similar case (assuming -x as shorthand for --onefilesystem),
under 'rm -frx foo/*' or 'cd foo && rm -frx *'
that was suggested as a replacement for the
desired rm -frx foo/. or 'cd foo && rm -frx .'
The first two forms of rm using '*' have no limit on the number
of file systems that can be affected.
Only the form 'foo/.' or '.' when used with --one-filesystem
will be actually limited to one-file-system.
If rmdir ever had a related but (now can have more so with -p),
it could also affect multiple dirs with 'rmdir foo/*'
Now you can't claim '*' is a somehow disallowed as it was
suggested as a workaround for disallowing rm -frx foo/.
But any form with 'rm' or rmdir can unsafely affect multiple
file systems on multiple systems, as users are told to use
shell-wildcards to make up for being unable to specify the
top level inside dir for deletion.
The reason things proably got so chaotic is that when it as
suggested that '*' be used with rm -frx *, one-filesystem was
no longer just 1 file system.
1) pray tell, why would it be called one file system when its
not? Now it's one-filesystem / root arg? Uh huh. That
sounds more than a bit specious to me.
2) if 'rm' really limited its deletes to 1 file system (ensuring
all it's cmd line args were on the same file system, Then the
same feature can be applied to rmdir to prevent it going from
touching different file systems in 1 command. Of couse with -p
as it back tracks, each back track and imply a change of
file system.
I can't find the original posts, but early comments applied to
'rm'. Some people seem to change titles of bugs without really
understanding what the root bug was about, so the fact that
something has rmdir in the title now doesn't really mean the
original was about rmdir.
Might want to examine that policy so things won't get as confusing --
adding on to a title in a separate field (gnu-summary), seems
like it might be less consusing that changing the original title.
That's my best guess at what this is about, but trying to recall
details where my original didn't seem to get posted back to me
(I thought it did, maybe things have chnaged in 6 years?).
-l
Since to delete all files under a directory with something
like (assuming '-x' for '--one-filesystem')
rm -frx * or rmdir * can all delete things on multiple
file systems.
Note, multiple responders, in discussing rm -frx
>
> Something like:
>
> mkdir testdir testdir/dir1 testdir/dir2 testdir/dir2/dir3
> rmdir --recursive testdir/dir2
> rmdir --version
>
> Include all input and output verbatim. For clarity do not use shell
> file glob wildcards because that is a dependence upon a specific
> command line shell and the shell's configuration.
>
>> dir1->dir2->dir3
>>
>> dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another.
>
> GNU Coreutils rmdir does not provide a recursive delete option.
> Therefore one can only assume that the rmdir you are referring to is a
> different rmdir from a different project.
>
> I specifically asked if you were using the rmdir --parents option but
> my message was the only mention of --parents in this entire ticket and
> in subsequent responses your messages also did not mention it.
> Therefore I can only assume that there is no --parents option being
> used here.
>
>>>> There is always 'find' with the -delete option. But regardless there
>>>> has been the find -exec option.
>> true -- so why should 'rm' protect against crossing boundaries
>> deleting '/' or everything under '.' when there is find?
>>
>> find is the obvious solution you are saying, so all that checking in
>> rm should be removed, as it is inconsistent with rmdir that can
>> cross boundaries.
>
> My mention of 'find' was really a simple statement about alternatives
> when programmatic needs are desired. Because 'find' is the swiss army
> chainsaw for directory traversal. I didn't mean to derail the
> discussion there. But if it is to be derailed then 'find' is the best
> choice when needing a specific set of programmatic requirements for
> directory traversal. The other utilities that have simpler
> capabilities are the distractions. But in theory this bug ticket was
> about 'rmdir'.
>
>> As for closing something not addressed for 6 years while the problem
>> has grown worse -- (rmdir didnt' used to have a recursive delete), doesn't
>> seem a great way to judge whether or not a bug is valid or not .
>
> GNU Coreutils rmdir does not provide a recursive delete option.
>
> This bug report so far has contained conflicting complaints to the
> point that it has not been useful. It still is not clear if you are
> complaining about 'rmdir' or 'rm' even after requests for
> clarification. Or possibly your shell's ** file glob expansion.
> Probably some combination of them all that is unique to your
> environment.
>
> To be useful a bug report must be descriptive so that the reader can
> understand it. If the reader can't understand it then how can it be
> useful? The report must be as simple as possible. Because extraneous
> complexity is distracting. Stay focused on the bug being reported and
> not about other unrelated things. Bugs about behavior should be
> reproducible with a test case. Because nothing is as useful as a
> concrete example.
>
> I have reviewed the reports in this ticket and there seems to be no
> viable bug report to operate upon here. At some point without a test
> case it only makes sense to say enough is enough and move on since
> this does not appear to be a bug in any program of the coreutils
> project. However even though a bug is closed discussion may continue
> as we are doing here. The bug state is simply a way to organize
> reports for the purposes of triage. Many thanks to Assaf for putting
> in the work to triage these old bug tickets.
>
> If you wish to report a bug in rmdir's recursive delete option then we
> must insist on a test case.
>
> Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Tue, 26 Feb 2019 20:11:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 12400 <at> debbugs.gnu.org (full text, mbox):
L A Walsh wrote:
> Bob Proulx wrote:
> > Please provide an example. Something small. Something concrete.
> > Please include the version of rmdir.
>
> The original bug stems from having to use wild cards to delete
> all files in a directory instead of '.', as in being told to use:
>
> rm -fr --one-filesystem foo/*
When reporting bugs in command line utilities it is good to avoid
using file glob wildcards in the test case. Because that involves the
shell. Because that makes the test case dependent upon the contents
of the directory which will then be expanded by the shell.
> instead of
>
> rm -fr --one-filesystem foo/. or
> cd foo && rm -fr --one-filesystem .
rm: refusing to remove '.' or '..' directory: skipping '.'
I agree with your complaint about "rm -rf ." not working. That is an
annoying nanny-state restriction. It should fail removing '.' after
having removed all it can remove. And it only took 16 messages in
order to get to this root cause! It would have been so much easier if
you had started there.
But this report is about rmdir so let's get back to rmdir. Any
reports about rm should be in a separate ticket. Mixing multiple bugs
in any one bug ticket is confusing and bad.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12400; Package
coreutils.
(Tue, 26 Feb 2019 20:35:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 12400 <at> debbugs.gnu.org (full text, mbox):
On 2/26/2019 12:10 PM, Bob Proulx wrote:
>> rm -fr --one-filesystem foo/. or
>> cd foo && rm -fr --one-filesystem .
>
> rm: refusing to remove '.' or '..' directory: skipping '.'
>
> I agree with your complaint about "rm -rf ." not working. That is an
> annoying nanny-state restriction. It should fail removing '.' after
> having removed all it can remove. And it only took 16 messages in
> order to get to this root cause! It would have been so much easier if
> you had started there.
>
> But this report is about rmdir so let's get back to rmdir. Any
> reports about rm should be in a separate ticket. Mixing multiple bugs
> in any one bug ticket is confusing and bad.
---
I think your example is where things started.
The issue with rmdir is a follow-on problem for not having
a "-x" option (don't delete from more than 1 file system),
and I recognized that from the fact that rm -fr no longer has
the ability to stay on 1 file system.
The only way you can delete files from under "." with 'rm',
and I have been told this NUMEROUS TIMES, is to use
the shell's expansion. While I would agree one should
remove the shell's expansion from the effects of a tool when
writing a bug report, the oft-quoted solution to
rm -fr . not following the original design, was to use
rm -fr *. With rm -fr *, rm no longer can delete files just
on 1-filesystem, let alone the 1 file system that the
top of the tree "." is on. If all subdirs underneath
"." (arbitrary directory as used in "rm -fr ."), are on
different file systems, as all are different mount points,
then there is no fixed limit as to how many file systems it
will affect.
Then people will say to use the find command -- which instantly
makes 'rm' worthless for the job for which it was intended.
If people want nanny behavior, like rm -i or even rm -I, let them
alias it that way. My main issue is one can't delete all
files under a directory with 'rm' anymore.
I've asked for it to only refuse to do so if POSIX_CORRECTLY
is set, or to add the converse IGNORE_POSIX_DOT_RESRICTIONS
(keeping the one for '/' -- as there is no reason to ever delete
'/' -- it's inefficient -- just remake the file system).
But as 'rm' was first designed, it did a depth first removal
and didn't preprocess the path looking for reasons to stop.
And I HAVE submitted multiple attemps to get rm-fr. to work
again. They are continuously shot down such that I often
have my own version of 'rm' that also removes empty
directories (behaving like 'rmdir'). It can't remove
'.' because it is in the dir and doesn't know the name to
remove from the parent, so that's still not affected.
If people have issues with rm having these changes, then
I have no problem adding 'r' as a new util that does --that
would not be bound by restrictions on 'rm', it would
1) allow "rm -fr .", deleting all but the current directory and
issue no error message due to the "-f".
and
2) delete empty directories without '-r' -- but only if it
knows their name -- i.e. it wouldn't delete '.'.
As it stands, the only reason this bug was filed was because
it's behavior is inconsistent with what is implemented in rm
in that it has no option to stay on 1 file system (which no
longer works in 'rm' due to previously cited reasons).
Creating such a utility would be trivial -- modify 'rm' to
allow processing the dirtree below "." and allow it to process
an empty directory.
So where would you suggest going from here to get to 'there'?
Linda
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 27 Mar 2019 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 41 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.