fs: fix partial write corruption in writeFile and writeFileSync

[olov]

1. writeFileSync bumps position incorrectly, causing it to
   drift in iteration three and onwards.
2. Append mode files will get corrupted in the middle if
   writeFile or writeFileSync iterates multiple times, unless
   running on Linux. position starts out as null so first write is
   OK, but then position will refer to a location inside an
   existing file, corrupting that data. Linux ignores position for
   append mode files so it doesn't happen there.

This commit fixes these two related issues by bumping position
correctly and by always using null as the position argument
to write/writeSync for append mode files.

fixes #1058
cc @piscisaureus

[piscisaureus]

Why the null check here?

[olov]

This is to fix 2. position may be null (see fs.writeFile caller) and without the check position will become a number instead, pointing to the middle of an existing file => corrupting data.

[piscisaureus]

Ah, got it, makes sense.

[bnoordhuis]

I think the check needs to be if (typeof position === 'number') {, else undefined or false will still trigger the bad behavior. It's also the condition that the documentation for fs.write() mentions.

[olov]

I don't see how position can become undefined or false in any of the two code paths.

[olov]

To elaborate, position is internal to writeFileSync and writeFile. In the latter case via an internal writeAll function that's only called from writeFile.

[piscisaureus]

Is it possible to add a test for the bug(s) this PR addresses too?

[olov]

I found it tricky and wasn't able to create anything suitable for inclusion in the PR. Perhaps others know more about how to deterministically test that "write-all" functions really work in the case of partial writes. Do you have any such tests already?

Anyways, this is a variant of the test I used to show issue 2. Do npm install posix; cp /usr/share/dict/words OUT and then sudo-run the script a number of times (between 1 and 10 usually) and you should see corrupted XXXXX showing up 40 bytes into OUT. Remember that issue 2 doesn't happen on Linux-systems (I tested on a Mac).

"use strict";

const fs = require("fs");
const posix = require("posix");
let limit = 40;

posix.setrlimit("fsize", {soft: limit, hard: limit});

const data = new Buffer(new Array(100).join("X"))

setTimeout(function() {
    console.log("upping limit");
    limit += 40;
    posix.setrlimit("fsize", {soft: limit, hard: limit});
}, 2);

fs.writeFile("OUT", data, {flag: "a"});

[olov]

Anything else needed here?

[piscisaureus]

Yeah, I don't know how to test this either.
Let's at least land this since it addresses a real bug.
LGTM

[piscisaureus]

Thanks @olov, landed in c9207f7.
Sorry it took a while to get back to you.

[olov]

Thanks @piscisaureus!