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.