rm bug?

[Thomas Klausner <wiz%NetBSD.org@localhost>]

Hi!

While debugging a test failure in the backup tool bup, I noticed the
following difference between NetBSD's and Linux' rm(1):

Linux

# mkdir -p a/b
# chmod 000 a/b
# rm -rf a
# ls -l a
ls: cannot access a: No such file or directory

NetBSD

# mkdir -p a/b
# chmod 000 a/b
# rm -rf a
rm: a/b: Permission denied
rm: a: Directory not empty
# chmod +x a/b 
# rm -rf a     
rm: a/b: Permission denied
rm: a: Directory not empty
# chmod -x a/b
# chmod +r a/b
# rm -rf a
# ls -l a
ls: a: No such file or directory

I can understand a bit why NetBSD's rm does not remove a directory
into which it cannot descend. However, I don't understand why allowing
it to descend is not enough (notice the failure after the "chmod +x"),
or why giving read permissions on the directory (INSTEAD of execute
permissions) is sufficient for rm(1) to delete it.

I think this is a bug. If there's a reason NetBSD's rm(1) doesn't
match the Linux behaviour, it should match it at least after the
"chmod +x".

Thoughts?
 Thomas