possible problem

[dominictarr]

I've recently been bitten by downloading files and writing them directly
to where I want them to live. If the program crashes before they are fully downloaded, then when it's started again, they program doesn't know that file is corrupt.

the solution is to stream to a temporary location, and then mv the files (fs.rename) it into position. the rename is atomic, so this means it fails or succeeds cleanly.

I'm not sure if problem will affect for code, because you are buffering.
but maybe it will, if the file size is greater than a block?

https://github.com/creationix/git-fs-db/blob/master/fs-db.js#L42-L47

[creationix]

What's wrong with partial writes? If the hash doesn't match the content, then we can tell it's corrupt after the fact. Or am in misunderstanding the problem?

[dominictarr]

sure, you could deal with it at one end or the other,
I only post this because this has bitten me recently,
and so I'm paranoid about it.

To me, It feels more complicated to handle that when you are reading, though.

[creationix]

Well, even with atomic writes using renames and temp files, you still have the issues of dangling references between files and other inconsistencies. We could add atomic writes to this db implementation (no reason not to), but it won't remove the need to check everything on read.