-
Couldn't load subscription status.
- Fork 881
rkt/image: lock temp files to avoid problems with concurrent fetches #2239
Conversation
When figuring out if we can resume a session, if we get a bad HTTP status, we were just returning without error and weren't resetting the session. This means we will download the full file *on top* of the already present file, which of course leads to a corrupted file. Reset the session in that case.
Whenever we create a Store temporary file, we lock it so concurrent downloads don't corrupt it.
|
Ping? |
|
How come the functional tests didn't catch the bug that got fixed by the first commit? |
IIRC, S3 is returning some 4xx error when trying to resume a download, which our test server doesn't. |
rkt/image/io.go
Outdated
| _, err = lock.TryExclusiveLock(tmp.Name(), lock.RegFile) | ||
| if err != nil { | ||
| if err != lock.ErrLocked { | ||
| return nil, err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add some text describing what failed? "failed to lock a file" or something?
|
This should prevent corrupting the image, but rkt will download the same image again. Not sure if we should worry about it in this PR. Anyway, one nit about error message, otherwise LFAD. |
|
Updated |
9d05ffc to
0a3f785
Compare
rkt/image: lock temp files to avoid problems with concurrent fetches
Whenever we create a Store temporary file, we lock it so concurrent
downloads don't corrupt it.
Fixes #2165