If I try to remove a symlink with a trailing slash on the end, it doesn't work correctly. Here's what happens. mkdir test touch test/testfile ln -s test test2 rm test2/ rm: remove directory `test2/'? y rm: remove regular empty file `test2//testfile'? y rm: remove directory `test2/'? y rm: cannot remove directory `test2/': Not a directory when it asks to remove the file testfile it actually does remove the file. And at the end it finally figures out it's a symlink apparently. Now if I just have an empty directory with a symlink to it, here's what happens when I try to remove the symlink. rm test2/ rm: remove directory `test2/'? y rm: remove directory `test2/'? y rm: cannot remove directory `test2/': Not a directory and without the trailing slash works fine. rm test2 rm: remove symbolic link `test2'? y somethings weird here. I have rm aliased to rm -i but I tried without -i and it does the same thing. I searched google and found a page describing a similar problem. http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00002.html I'm not sure what this bug is coming from but I figured it's a fileutils problem, as I've been able to remove symlinks with or without trailing slashs on other distros using older versions of fileutils (4.1). Also from http://www.gnu.org/software/fileutils/fileutils.html it says "The version fileutils-4.1.9 Jim notes as possibly more dangerous than previous versions because he has rewritten rm. See the accompanying NEWS file for details. You have been warned!" I tried the 4.1.8 ebuild and I get a similar problem. Shouldn't there be a 4.1 ebuild, as 4.1 is the stable version?
rom: Jim Meyering <jim@meyering.net> To: Seemant Kulleen <seemant@gentoo.org> Cc: bug-coreutils@gnu.org Subject: Re: Bug: Symlink removal. Date: Thu, 20 Mar 2003 13:50:21 +0100 Thank you for the report. Here's some previous discussion on the matter: http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00006.html rm fails to remove a symlink specified with a trailing slash because the unlink syscall also fails for such an argument. Making rm detect that condition earlier would not be hard, but would incur some cost -- cost to be borne by non-failing uses of rm. You might want to incur the cost only when prompting the user, but then that'd make rm behave differently with -i than without. The reason it used to work is because older versions of rm (prior to the rewrite for fileutils-4.1.9) improperly removed any trailing slashes. POSIX prohibits that. I admit that the diagnostics are contradictory, and I may well fix that some day, but it's not a high priority.
coreutils handle this a bit different, mkdir test touch test/testfile ln -s test test2 rm test2/ rm: remove directory `test2/'? y rm: cannot remove directory `test2/': Not a directory Looks okay, IMHO. Could you check this and maybe close the bug? Or let the bug assigned to yourself or reassign them, IMHO bugs shouldn't be assigned to bug-wranglers for a long term.
I forgot all about this bug... I'm using the ~x86 coreutils now, and with it rm test2/ rm: cannot remove directory `test2/': Is a directory and just to make sure.. rm test2/ -rf rm: cannot remove `test2/': Not a directory it doesn't even ask for a confirmation. I have rm aliased to rm -i. Although something odd happens when I do this. rm -rf test2/ -i rm: descend into directory `test2/'? y rm: remove regular empty file `test2//testfile'? y rm: remove directory `test2/'? y rm: cannot remove directory `test2/': Not a directory which is actually running rm -i -rf test2/ -i and now it acts like it did before. Weird. It seems whether or not I use -f doesn't matter to reproduce that. Also, the first -i can be removed completely as well, and it still happens with rm -r test2/ -i for example. For the most part, it seems the behavior is fixed. The above may be a new bug in coreutils.
this is rather stuff that upstream maintainers should know about.
