-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconcile history from image manifest and config #17
Conversation
filetree/tree.go
Outdated
@@ -20,6 +20,7 @@ const ( | |||
type FileTree struct { | |||
Root *FileNode | |||
Size int | |||
FileSize int64 |
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.
Should we use uint64
here? The value can't be negative...
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.
👍
fmt.Println(err) | ||
os.Exit(1) | ||
} | ||
defer tarFile.Close() |
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.
Should the defer tarFile.Close()
be immediately after os.Open()
? Is there any situation where the code gets a file handle but then exits 1 before closing it?
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.
I'm not certain if there is a case where the file is open before exit is called, however, I still think this is the preferred way to go for a couple reasons:
- os.Exit cleans up file descriptors (in case the file was open but there was another error)
- since we're not guaranteed to have an open file we shouldn't attempt to close it until after we've checked it was opened with no error.
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.
That makes sense.
Pulling history from the docker API doesn't make sense for two reasons:
empty_content
bool, and inferring this from thecreated_by
attribute is not accurate (sometimes a layer with content has acreated_by
attribute that starts with anop
statement).Downside is that we have to calculate the layer size manually, but since we're already iterating across all contents, I don't see the harm. The upside is that we're not coupling to a docker API type?
This will require further cleanup.