Subject: more mkdir foo/ problems
To: None <tech-kern@netbsd.org>
From: Julian Assange <proff@iq.org>
List: tech-kern
Date: 02/07/2000 00:33:43
jar xf ../B.jar
java.io.IOException: images/: could not create directory
        at sun.tools.jar.Main.extractFile(Main.java:387)
        at sun.tools.jar.Main.extract(Main.java:367)
        at sun.tools.jar.Main.run(Main.java:98)
        at sun.tools.jar.Main.main(Main.java:518)

It looks like this should be sysctlable for compatability testing.

e.i sysctl -w proc.curproc.compat.aft_slash_ok=1, on by default.

Does posix have anything to say about the matter?

We must first consider current internal inconsistancies. For
example, while mkdir("foo/") fails, rmdir("foo/") does not, and
neither does stat("foo/",..) and for the purposes of symlink
resolution, "foo/" is "foo/.". Yet rmdir("foo/.") fails clearly showing
that "foo/" and "foo/." are conceptually different, denying possible
claims that mkdir("foo/") is really mkdir("foo/.") and thus the semantic
evil that goes with it.

Consequently, I believe that there is a strong case for permitting
mkdir("foo/")'s claims of benevolence.

--
   Warren Air Force Base in Cheyenne, Wyoming, recorded a message that
   one of its Minuteman III intercontinental ballistic missiles was
   about to launch from its silo due to a computer malfunction. To
   prevent the possible launch, an armored car was parked on top of
   the silo.

     - Shaun Gregory, The Hidden Cost of Deterrence: Nuclear Weapons
       Accidents, Brassey's UK, London, 1990, pp. 181-182.