| Summary: | e2image generates corrupted raw image to standard out when -p flag used | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alex Markley <alex> |
| Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 23 | CC: | esandeen, josef, kzak, oliver |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-15 18:49:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Thanks for the report; looks like it's just "Scanning inodes..." which isn't printed to stderr; I'll send a patch upstream. Is this something you need fixed in f23? Thanks, -Eric (In reply to Eric Sandeen from comment #1) > Thanks for the report Thank you for responding so quickly! I saw the same code and I thought it was something like this. > Is this something you need fixed in f23? Nope. Working around the issue by dropping the -p flag is fine for me. Thanks again! Ok, I'll just close this as UPSTREAM then and we'll pick it up on the next release. -Eric |
Description of problem: e2image offers the capability to display progress data on the terminal while running. This feature is enabled using the -p flag. However, when directing an image to standard out, some of the progress data leaks into the image stream, corrupting the image. Version-Release number of selected component (if applicable): e2fsprogs-1.42.13-3.fc23.x86_64 How reproducible: Completely Steps to Reproduce: ### Follow along: $ e2image -r /dev/sdb2 - | gzip --best >TestNoProgress.e2img.gz e2image 1.42.13 (17-May-2015) $ e2image -rp /dev/sdb2 - | gzip --best >TestWithProgress.e2img.gz e2image 1.42.13 (17-May-2015) Copied 16343 / 16343 blocks (100%) in 00:00:28 at 2.28 MB/s s ### Decompressed images should be identical, but they are not. $ zcat TestNoProgress.e2img.gz | sha256sum d6551e9e979fb46b4f828cb1dccfc7babbf994187f5d869b155c316b2505cc6a - $ zcat TestWithProgress.e2img.gz | sha256sum 22fbf3f1e9a6daec5c52d6b16e17efadd75ecc8986e5adc3965e089b5b14d613 - ### With -p is 19 bytes longer. $ zcat TestNoProgress.e2img.gz | wc -c 3699376128 $ zcat TestWithProgress.e2img.gz | wc -c 3699376147 ### Comparing the last 4K (+/- 19 bytes) you can see the culprit. $ zcat TestNoProgress.e2img.gz | tail -c 4096 | hexdump -Cv >TestNoProgress.e2img.footer $ zcat TestWithProgress.e2img.gz | tail -c 4115 | hexdump -Cv >TestWithProgress.e2img.footer $ diff TestNoProgress.e2img.footer TestWithProgress.e2img.footer 257c257,259 < 00001000 --- > 00001000 53 63 61 6e 6e 69 6e 67 20 69 6e 6f 64 65 73 2e |Scanning inodes.| > 00001010 2e 2e 0a |...| > 00001013 Actual results: Generated image should be the same regardless of the -p flag. Generated image should never contain progress data. Expected results: When using the -p flag, progress data leaks into the image, corrupting it. Additional info: N/A