Your message dated Mon, 28 Apr 2025 16:13:35 -0400
with message-id <[email protected]>
and subject line Re: Bug#1104300: coreutils: rm -d fails to remove non-empty
directory
has caused the Debian Bug report #1104300,
regarding coreutils: rm -d fails to remove non-empty directory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1104300: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104300
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: coreutils
Version: 9.7-2
Severity: normal
X-Debbugs-Cc: [email protected]
Dear Maintainer,
On CephFS, creating a snapshot is done suchly:
$ mkdir .snap/snapshot-name
This creates a directory which contains a view of the current directory
at the time the snapshot was created, and is therefore non-empty if the
current directory was non-empty at that time. Its contents are immutable.
Removing a snapshot is done suchly:
$ rmdir .snap/snapshot-name
This works fine even if .snap/snapshot-name is non-empty, as rmdir calls
rmdir(2) directly without trying to be smart, and the Ceph filesystem
understands what rmdir on a snapshot directory means: remove the snapshot.
One would naturally expect rm -d to behave *exactly the same* as rmdir,
but this isn't the case, because rm -d first does a getdents on the
directory, observes it is non-empty, and refuses to perform the removal.
I understand this is non-compliant behavior per XCU rm 2.a. and 4. and
XSH remove().
Moreover other coreutils implementations (such as uutils or voreutils)
do not exhibit this bug and correctly remove non-empty directories.
Regards,
Yannick Le Pennec
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.12.22-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages coreutils depends on:
ii libacl1 2.3.2-2+b1
ii libattr1 1:2.5.2-3
ii libc6 2.41-7
ii libcap2 1:2.75-7
ii libgmp10 2:6.3.0+dfsg-3
ii libselinux1 3.8.1-1
ii libssl3t64 3.5.0-1
ii libsystemd0 257.5-2
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Mon, Apr 28, 2025 at 03:36:40PM +0200, Yannick Le Pennec wrote:
This works fine even if .snap/snapshot-name is non-empty, as rmdir calls
rmdir(2) directly without trying to be smart, and the Ceph filesystem
understands what rmdir on a snapshot directory means: remove the snapshot.
One would naturally expect rm -d to behave *exactly the same* as rmdir,
but this isn't the case, because rm -d first does a getdents on the
directory, observes it is non-empty, and refuses to perform the removal.
I understand this is non-compliant behavior per XCU rm 2.a. and 4. and
XSH remove().
Moreover other coreutils implementations (such as uutils or voreutils)
do not exhibit this bug and correctly remove non-empty directories.
Not a bug. The man page for rm -d says "remove empty directories". It is
unfortunate that SUS decided to define -d differently after coreutils
had already started using for something else (especially since the new
definition disagrees with both the historic useage *and* the useage in
at least one existing implementation). Debian isn't going to deviate
from upstream on this. If you wish to run rmdir, just run rmdir.
--- End Message ---
