guiyanakuang opened a new pull request #941:
URL: https://github.com/apache/orc/pull/941
1. The original code was not aware of the possibility of OrcFileMAGIC being
separated
2. The indexOf method does not match correctly
<!--
Thanks for sending a pull request! Here are some tips for you:
1. File a JIRA issue first and use it as a prefix of your PR title, e.g.,
`ORC-001: Fix ABC`.
2. Use your PR title to summarize what this PR proposes instead of
describing the problem.
3. Make PR title and description complete because these will be the
permanent commit log.
4. If possible, provide a concise and reproducible example to reproduce
the issue for a faster review.
5. If the PR is unfinished, use GitHub PR Draft feature.
-->
### What changes were proposed in this pull request?
<!--
Please clarify what changes you are proposing. The purpose of this section
is to outline the changes and how this PR fixes the issue.
If possible, please consider writing useful notes for better and faster
reviews in your PR. See the examples below.
1. If you refactor some codes with changing classes, showing the class
hierarchy will help reviewers.
2. If there is a discussion in the mailing list, please add the link.
-->
This pr is aimed at fixing some bugs where the Java Tools recovery file
command did not accurately find OrcFileMAGIC.
```java
while (remaining > 0) {
int toRead = (int) Math.min(DEFAULT_BLOCK_SIZE, remaining);
byte[] data = new byte[toRead];
long startPos = corruptFileLen - remaining;
fdis.readFully(startPos, data, 0, toRead);
// find all MAGIC string and see if the file is readable from there
int index = 0;
long nextFooterOffset;
byte[] magicBytes = OrcFile.MAGIC.getBytes(StandardCharsets.UTF_8);
while (index != -1) {
index = indexOf(data, magicBytes, index + 1);
if (index != -1) {
nextFooterOffset = startPos + index + magicBytes.length + 1;
if (isReadable(corruptPath, conf, nextFooterOffset)) {
footerOffsets.add(nextFooterOffset);
}
}
}
System.err.println("Scanning for valid footers - startPos: " +
startPos +
" toRead: " + toRead + " remaining: " + remaining);
remaining = remaining - toRead;
}
```
Two adjacent reads may be exactly separated by OrcFile.MAGIC, making it
impossible to find the location of the recovered file. Because the current
implementation only matches in a single read.
```java
private static int indexOf(final byte[] data, final byte[] pattern, final
int index) {
if (data == null || data.length == 0 || pattern == null ||
pattern.length == 0 ||
index > data.length || index < 0) {
return -1;
}
int j = 0;
for (int i = index; i < data.length; i++) {
if (pattern[j] == data[i]) {
j++;
} else {
j = 0;
}
if (j == pattern.length) {
return i - pattern.length + 1;
}
}
return -1;
}
```
This matching algorithm is wrong when i does not backtrack after a failed
match in the middle. As a simple example data = OOORC, pattern= ORC, index = 1,
this algorithm will return -1.
### Why are the changes needed?
<!--
Please clarify why the changes are needed. For instance,
1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, you can clarify why it is a bug.
-->
Fix some bugs that Java Tools recovery file command cannot find OrcFileMAGIC
accurately.
### How was this patch tested?
<!--
If tests were added, say they were added here. Please make sure to add some
test cases that check the changes thoroughly including negative and positive
cases if possible.
If it was tested in a way different from regular unit tests, please clarify
how you tested step by step, ideally copy and paste-able, so that other
reviewers can test and check, and descendants can verify in the future.
If tests were not added, please describe why they were not added and/or why
it was difficult to add.
-->
Add UT.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
