Zip won't create a new file, expects it to be present

[gchiu]

>> zip %something.zip ["foo"]
(i) Info: use WHY for error information
** Access Error: cannot open: %something.zip reason: make error! [
    type: '
    id: '
    message: "no such file or directory"
    near: '
    where: '
    file: '
    line: '
]

[hostilefork]

Two problems here.

problem 1: you used the dialect wrong

The zip dialect expects you to give it filenames, and then optionally data. You only gave it data. It wouldn't know what to call the file it put "foo" into when the UNZIP happened. So you'd have to say instead:

zip %something.zip [%foo.txt "foo"]

(I don't know if the zip dialect is ideal, in the semantics that [%foo.txt "foo" %bar.txt #{BABA}] stores data out of the block under those names and [%foo.txt %bar.txt] will assume you want the contents of existing files. Seems easy to screw up. Though maybe commas could make it clearer? [%foo.txt, %bar.txt]. This is a whole discussion that needs to be had on the forum about dialects.)

problem 2: libuv change is taking refinements more literally

Looks like in the libuv migration when the opening flags were supplied I mapped them precisely, e.g. open/write does not convey /new. So if you want to open a file with write access and create a new file you have to say open/write/new. This means OPEN/WRITE will assume you are opening an existing file for write access.

I don't know what the best ergonomics are here but certainly requiring the /NEW is more conservative. We should look at what the verb CREATE is supposed to do; unsurprisingly the philosophy here wasn't ever really articulated.

Addressed in:

https://github.com/metaeducation/ren-c/commit/1ac1a0b5fc325598141d33c0926946d1b978ba39