gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/19/85)
I think the SVR2 "rm" utility has a serious bug; since my version has been heavily modified, I'm not entirely sure about the unmodified version. To see if you have the bug, try the following: $ mkdir foo foo/bar $ touch xxx foo/xxx foo/bar/xxx $ rm -r foo/bar xxx $ ls -R xxx foo You should see that "xxx", "foo/bar/xxx", and "foo/bar" no longer exist and "foo" and "foo/xxx" still exist. Any other result indicates that your "rm" has the bug. There is also a separate bug in the code that checks for attempts to "rm ..". The fixes for these were too extensive to try to post; if you have received the BRL UNIX System V emulation for 4.2BSD before this posting, send me a note and I'll mail you the corrected source.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/25/85)
Reports from actual UNIX System V Release 2 sites indicate that the original SVR2 "rm" does not have the particular bug that I reported a few days ago. Sites that have not modified their version of "rm" in an attempt to fix some of its other problems should not worry about this one. Sites that have picked up the "rm -r" fix reported to the net long ago should check for the bug. Known possible rm problems: 1) "rm -r" fails when total number of chars in path reaches 100. 2) "rm -r" fails when directories are deeply nested (20 levels). 3) "rm -r" reads directories directly rather than using directory access library routines. 4) "rm .. other_args" fails to remove other_args. 5) "rm -r", when patched to fix problem # 1, may fail to work in cases like "rm -r foo/bar x". Recent BRL System V emulation distributions fixed problems # 1,2,3 but introduced problem # 5. This has now been fixed, along with # 4. I'm beginning to think that the best way to fix problems in system software is to totally rewrite it.