GitLab

As CdmFileIO writing is now asynchronous, it is possible for a write()
call that is cancelled by calling close() before the write callback is
called to actually succeed (or partially succeed). Normally that is not
a problem as the implementation of write creates a temporary file,
writes to it, and then renames the file to the actual file name as a
final step. However, if the write() is part way through the process
when it is cancelled, it may leave a temporary file around. Next time
write() is called, it will overwrite the existing temporary file. If
the new contents are shorter than what is in the file, then extra data
will be returned when the file is read later.

The fix is to truncate the temporary file if it exists. So in the rare
case that a temporary file is left around, it will be reset to 0 bytes
before writing to it.

This CL also updates all the FileIO tests that do this (call close()
immediately after calling write() without waiting for write() to
succeed). They will now check for one of the two buffers to be returned
on the next read(), as the second write() may have actually succeeded
before close() was called.

This should fix the code, so re-enabling the browser_tests that were
flaky.

Bug: 999421,997953
Test: Re-enabled tests succeed
Change-Id: Ib1772b678c7e89f588e81cc40055650478e6a9e2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1793722Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: John Rummell <jrummell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#699144}