GNU bug report logs -
#24730
rmdir/mkdir error(s) and/or not working "reciprocally" w/each other
Previous Next
Reported by: "L. A. Walsh" <coreutils <at> tlinx.org>
Date: Tue, 18 Oct 2016 20:02:02 UTC
Severity: normal
Tags: notabug
Done: Eric Blake <eblake <at> redhat.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 24730 <at> debbugs.gnu.org.
--
24730: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24730
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
tag 24730 notabug
thanks
On 10/18/2016 02:49 PM, L. A. Walsh wrote:
>
> It doesn't seem rmdir and mkdir are behaving "reciprocally"...
>
> If I type
>
> mkdir -p ./a/b/c # no error
. already exists, so mkdir silently does nothing,
./a needs to be created,
./a/b needs to be created,
./a/b/c needs to be created
> rmdir -p ./a/b/c # get error msg, but a,b,c removed.
./a/b/c needs to be removed,
./a/b needs to be removed,
./a needs to be removed,
. needs to be removed, but you can't do that, hence the error
The apparent asymmetry is due to the POSIX rules on how '.' is treated;
but we can't change the behavior of either of these commands, because
they are both following the POSIX rules.
If you want symmetry, omit the leading './', as in:
$ mkdir -p a/b/c
$ rmdir -p a/b/c
>
> 1) thinking either rmdir shouldn't generate an error or mkdir should
>
> mkdir -p a/../b # no error
a needs to be created,
a/.. already exists, so it silently does nothing,
a/../b needs to be created
> rmdir -p a/../b # error, but a & b removed
a/../b needs to be removed,
a/.. needs to be removed, but you can't do that,
at this point, POSIX is fuzzy whether to attempt to remove 'a', or to
give up since 'a/..' was already an error; but obviously coreutils
removes 'a'
>
> 2) similar comment to above -- leading to:
>
> for rmdir, if "-p" is used, then as similar to "mkdir -p":
> (no error if existing, make parent directories as needed)
>
> rmdir -p should be
> "no error if dir not empty, but directories are followed
> and deleted as possible".
Sadly, while that might be a nicer definition for 'rmdir -p', it doesn't
match the POSIX requirements nor the historical behavior, so we can't
really change it now.
So I'm marking this as not a bug, as there is nothing to change.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
[Message part 5 (message/rfc822, inline)]
It doesn't seem rmdir and mkdir are behaving "reciprocally"...
If I type
mkdir -p ./a/b/c # no error
rmdir -p ./a/b/c # get error msg, but a,b,c removed.
1) thinking either rmdir shouldn't generate an error or mkdir should
mkdir -p a/../b # no error
rmdir -p a/../b # error, but a & b removed
2) similar comment to above -- leading to:
for rmdir, if "-p" is used, then as similar to "mkdir -p":
(no error if existing, make parent directories as needed)
rmdir -p should be
"no error if dir not empty, but directories are followed
and deleted as possible".
======> seems to be best wording & solution:
"mkdir -p", it seems should really be restated to:
follow given path and make directories as possible"
then "rmdir -p" could be
"follow given path and delete directories if empty"
Does that look reasonable?
linda w.
This bug report was last modified 8 years and 241 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.