Summary: | fileutils symlink removal problem | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jordan <xero> |
Component: | New packages | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jordan
2003-03-19 15:05:33 UTC
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. |