Description of problem: This looks to be similar to or a regression of: https://bugzilla.redhat.com/show_bug.cgi?id=473662 The latest update of the coreutils package causes "rm -d" or "rm --directory" to be a noop and throw and error message. The -d/--directory option are still listed in the man page for rm, but have been removed from the GNU coreutils documentation: http://www.gnu.org/software/coreutils/manual/coreutils.html#rm-invocation The behavior of -d/--directory is likely deprecated, but some software uses the options. One example is the VMware tools install kicked off by template customizations. All such customizations fail near the end of installation when the cleanup kicks off. The tools install/template customization steps perform a "rm -drf" or something similar, which errors out and causes template customization steps to fail. As we use a number of RHEL 5.4-based VMware templates, this unexpected (and undocumented) change is causing us issues. This RHN fix is the one responsible for the change: http://rhn.redhat.com/errata/RHBA-2009-1511.html Version-Release number of selected component (if applicable): Red Hat Enterprise Linux 5.4 coreutils RPM package, version 5.97-23.el5_4.1 How reproducible: Always - the documented and expected behavior has been removed. Steps to Reproduce: 1. Update to latest version of coreutils RPM. 2. Attempt to run an "rm -d" or variant thereof. 3. Be presented with noop/deprecation message, though option is still in man page. Actual results: # whoami root # cd /tmp/ # mkdir test # touch test/testfile # rm -drf test Warning: --directory (-d) option is undocumented and no-op. Use -rf for deleting non-empty dirs # ls test/ testfile # cat /etc/redhat-release CentOS release 5.4 (Final) # rpm -qf /bin/rm coreutils-5.97-23.el5_4.1 Expected results: # whoami root # cd /tmp/ # mkdir test # touch test/testfile # rm -drf test # ls -d test ls: test: No such file or directory # cat /etc/redhat-release CentOS release 5.3 (Final) # rpm -qf /bin/rm coreutils-5.97-19.el5 Additional info: As evidenced above, works as expected with coreutils-5.97-19.el5 package. Installing the old version of the package allows VMware templates customizations to complete successfully, so this is definitely an issue/regression with the updated package.
Just wanted to provide a RHEL version of the above as well - examples above are CentOS, but this is occurring on the latest update of Red Hat Enterprise Linux as well: [root@host ~]# cd /tmp/ [root@host tmp]# mkdir test [root@host tmp]# touch test/testfile [root@host tmp]# rm -drf test Warning: --directory (-d) option is undocumented and no-op. Use -rf for deleting non-empty dirs [root@host tmp]# uname [root@host tmp]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga) [root@host tmp]# rpm -qf /bin/rm coreutils-5.97-23.el5_4.1
Thanks for report... In fact it was more caused by http://rhn.redhat.com/errata/RHBA-2009-1262.html 5.4 update. I just wonder why VMware does call -d option to rm - this option was just confusing and noop in RHEL-4/5 - initial RHEL-5 report is https://bugzilla.redhat.com/show_bug.cgi?id=473472 ... Additionally, -d is not specified by POSIX ( http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html ) - so is not granted to be portable and present in 'rm' like utilities (e.g. busybox rm doesn't have other than posix options + -v (which is ignored)). AFAIK - the option '-d' was removed from --help, info and man page by the update - so if it is still present in your manpage, you probably use different than coreutils manpage (it could be shipped by man-pages-<locale> package - those pages are in many cases very outdated). Additionally - change only prints deprecation warning on stderr - so it should have NO impact on rm -drf functionality - as the -r option is unaffected - no error exit code. It works on my machine: [Reset@localhost epel-5-i386]$ ls buildroot.lock result rm root test [Reset@localhost epel-5-i386]$ ./rm -drf test Warning: --directory (-d) option is undocumented and no-op. Use -rf for deleting non-empty dirs [Reset@localhost epel-5-i386]$ ls buildroot.lock result rm root Could you please make strace of this failing rm -drf command? TIA.
In needinfo for more than one month, closing NOTABUG. It works for me as expected - just showing -d warning but not affecting -rf functionality. Please add the strace and/or more information, if you want to reopen the bug in future.