Bugzilla – Full Text Bug Listing
| Summary: | BinaryResourceImpl better reporting/handling for bad data | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Miles Parker <milesparker> |
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | 2.7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Miles Parker
I'm not sure what can really be done. It's not human readable so how is one going to fix some ugly bytes? I can't imagine anything that's terribly useful except to use the debugger. What really would you do with such information and why couldn't you gather it with the debugger? (In reply to comment #1) > I'm not sure what can really be done. It's not human readable so how is one > going to fix some ugly bytes? I can't imagine anything that's terribly useful > except to use the debugger. What really would you do with such information and > why couldn't you gather it with the debugger? I'm thinking of end-user scenario here where the suggestion of "just use the debugger" would not go over so well. ;) What I want to do in a context where we do have some bad bytes is to recover the file itself while excising a bad piece of it and reporting that it had been chomped. Does that make more sense? (To be clear, "慣敎慭攌䥮摩慮愬⁕匊潵牣敃潮瑥湴ࡉ湤楡湡ఋ捯" *Is* probably human readable, just not by me (without a dictionary) and perhaps not by you.) I wonder if perhaps it would work better to not use the OPTION_STYLE_BINARY_FLOATING_POINT option? Parsing doubles is the only area where this has been an issue and I wonder if moving between the XML and Binary file encoding might be messing something up. I don't think a corrupted byte stream can be fixed by humans. One wrong byte and you have only noise. There shouldn't be a problem with mismatched options because the important options that affect processing are stored and should be respected. There was a bug that was committed in this regard though and it sounds like you might be using the version that had that bug. (In reply to comment #4) > I don't think a corrupted byte stream can be fixed by humans. One wrong byte > and you have only noise. There shouldn't be a problem with mismatched options If it is a mangled byte rather than a missing one then everything else will remain aligned. It should be possible then to simply look for the next expected tag, right? I'm not saying that we should do this now, just a thought. > because the important options that affect processing are stored and should be > respected. There was a bug that was committed in this regard though and it > sounds like you might be using the version that had that bug. I'll check. I was building on M4 and I'll see if it happens under M5. No, the assumption that a mangled byte leaves the rest of the stream intact isn't valid. Many of the bytes record information about how many bytes follow, i.e., the size of a list, the length of a string. Even int values (for object IDs, for example) are often written compressed in such a way that smaller values use fewer bytes so even here, a wrong byte will wreak havoc from which there is no recovery. Hi Ed, I'm good with this resolution if you want to go ahead and close it as INVALID or whatever. I see you fixed the underlying issue, thanks. Miles It's hard to do much that would be truly useful... |