d99756a8a2
To make restarting after failed pull less racy, we define `Truncate(size int64) error` on `content.Writer` for the zero offset. Truncating a writer will dump any existing data and digest state and start from the beginning. All subsequent writes will start from the zero offset. For the service, we support this by defining the behavior for a write that changes the offset. To keep this narrow, we only support writes out of order at the offset 0, which causes the writer to dump existing data and reset the local hash. This makes restarting failed pulls much smoother when there was a previously encountered error and the source doesn't support arbitrary seeks or reads at arbitrary offsets. By allowing this to be done while holding the write lock on a ref, we can restart the full download without causing a race condition. Once we implement seeking on the `io.Reader` returned by the fetcher, this will be less useful, but it is good to ensure that our protocol properly supports this use case for when streaming is the only option. Signed-off-by: Stephen J Day <stephen.day@docker.com> |
||
|---|---|---|
| .. | ||
| content | ||
| execution | ||