pkg/daemon: write bytes, use buffered writer and compare bytes #411
Conversation
openshift-ci-robot
added
the
size/XS
runcom
force-pushed
the
buffer-file-encoding
branch
from
57d1269
to
3bd435e
Compare
|
/lgtm |
|
Good catch! /lgtm I think we need the same thing in |
|
/hold @runcom do you want to update ``checkFileContentsAndMode()` in this PR or keep them separate? |
openshift-ci-robot
added
the
do-not-merge/hold
I'll push to this PR |
runcom
force-pushed
the
buffer-file-encoding
branch
from
3bd435e
to
b609251
Compare
|
pushed with changes to the other func, ptal |
openshift-ci-robot
added
size/S
|
All unit tests passed, but reported failure 😕 /test unit |
|
Ahh the failure was only noted in the full log: |
|
yeah, there's an error I'm fixing |
|
Looks good to me. Though the commit message title could be tweaked now that it also fixes the reading side as well. |
yup, I'll change it once I fix the unit tests 👍 |
runcom
force-pushed
the
buffer-file-encoding
branch
from
b609251
to
5edb59c
Compare
runcom
changed the title
|
updated and changed commit message/title as well |
| @@ -881,8 +882,8 @@ func checkFileContentsAndMode(filePath, expectedContent string, mode os.FileMode | |||
| glog.Errorf("could not read file: %q, error: %v", filePath, err) | |||
| return false | |||
| } | |||
| if strings.Compare(string(contents), expectedContent) != 0 { | |||
| glog.Errorf("content mismatch for file: %q; expected: %v; received: %v", filePath, expectedContent, string(contents)) | |||
| if !bytes.Equal(contents, expectedContent) { | |||
There was a problem hiding this comment.
this should now be much faster compared to string methods as it's directly implemented in assembly as well
pkg/daemon/daemon.go
Outdated
| if strings.Compare(string(contents), expectedContent) != 0 { | ||
| glog.Errorf("content mismatch for file: %q; expected: %v; received: %v", filePath, expectedContent, string(contents)) | ||
| if !bytes.Equal(contents, expectedContent) { | ||
| glog.Errorf("content mismatch for file: %q; expected: %v; received: %v", filePath, expectedContent, contents) |
There was a problem hiding this comment.
Hmm, this will print the contents as a byte array, right? We could not print the raw contents at all, though it's definitely helpful if it is indeed human-readable text (which it likely is in most cases). WDYT about casting to string here before printing and otherwise fallback on printing as a byte array?
I'm good with this as is too though and doing that as a follow up.
There was a problem hiding this comment.
the issue is casting to string a bytes slice always succeeds, not sure how to differentiate if we can't show something, I'm not really sure this info is helpful for big files as well 🤔
There was a problem hiding this comment.
How about we just tweak it to "content mismatch for file: %q" for now?
`contents.Data` is a byte slice and can be anything (i.e. a binary after deconding). Use a bytes writer to prevent misbehaves in such scenarios. Along with that, use a buffered writer around the file in case we're dealing with big files. Also, compare byte slices as well instead of using strings. Signed-off-by: Antonio Murdaca <runcom@linux.com>
runcom
force-pushed
the
buffer-file-encoding
branch
from
5edb59c
to
610f216
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ashcrow, cgwalters, jlebon, runcom The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/retest |
contents.Datais a byte slice and can be anything (i.e. a binary afterdeconding). Use a bytes writer to prevent misbehaves in such scenarios.
Along with that, use a buffered writer around the file in case we're
dealing with big files. Also, compare byte slices as well instead of
using strings.