UPDATE_SNAPSHOTS=1 Appears to corrupt .snap file

[jacobgardner]

If there are multiple tests updating a .snap file, it appears to cause some corruption.

How to reproduce:

1. Add a bunch of tests to the same file so they'll all be writing to the same place.
2. Delete existing corresponding .snap file.
3. Run UPDATE_SNAPSHOTS=1 cargo test

Sometimes it'll work if you have a few tests, but most of the time this causes a corrupt file on my machine.

Rust tests run in parallel so the test executables are probably grabbing the same file and writing to it simultaneously.

Easiest way to fix this is probably using file-locking from a crate like fs2. I'll try making a PR with that.

Edit: Realized that the files being written to are only being written to by a single test file so it's probably not what I thought it was. Investingating...

Edit V2: Now it just sort of feels like the files aren't being flushed by the time File::open is called the next time. Pretty sure files get flushed when they get dropped though...

Edit V3: Nevermind, back to my original theory. There's definitely some multithreading issue going on here.

[jacobgardner]

Was able to confirm that it was indeed a multithreading issue.

For 3 tests (and no snap file), 3 threads were opening and reading the same file 3 times. Each time it read the file, it was empty. Then each of the three threads proceeded to write their snapshot to the output file. Without truncation on, this was causing a weird corruption because the longest result would be peeking out at the end and the last to write would be at the start of the JSON.

I was able to fix this bug in my branch, but I've got a little clean up to do before making a PR.

Edit: Here's my branch for reference https://github.com/jacobgardner/snapshot-rs/tree/corrupted-snap-files

[jacobgardner]

Also if any one has a suggestion for writing a test to cover this for regression purposes, please let me know. I haven't the faintest idea of how I would write a test for this bug right now.