Fix handling contents added after header creation #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If additional contents have been appended to a file after the
Header
is created but before the file contents are written to the archive the archive can become corrupted.Such that a
tar -tf
on the resulting archive reveals the following errors:OS X
Linux
Criteria for likelihood of encountering the issue
The closer a process gets to spamming to their log file the more likely this issue is to occur (e.g. hubCore, ncpHost will be top contenders).
Hubs which have a lot of devices, behaviors, drivers, etc. will as a result be more likely to hit this.
Increasing log levels obviously contributes to this.
Inspection of a corrupt archive
Upon inspecting the corrupted archive we see that:
hubCoreLog
starts at 0x0032c400hubCoreLog
file size in octal is 07114433 == 0x1C991B. So the next record should start at0x4F5E00
(because this calculation is rounded up to the nearest 512 byte alignment).hubCoreLog
entry exceeds what the header specifiesProposed solution
To solve the issue we limit the amount of data that can be read from the file to whatever was available at the time of creating the
Header
. This doesn't account for if bytes were removed from a file, I think that may be a more involved change but I haven't spent much time considering it. And that is a far less likely scenario to hit in practice.Testing
I have only been able to intermittently reproduce the issue, but have yet to hit it with this fix. I'll be doing additional testing to get some more data.
https://smartthings.atlassian.net/browse/CHAD-8045