BUG REPORT
Describe the bug
While analyzing the implementation of FileInfo.moveToNewLocation, I noticed a condition that appears to be unreachable.
Specifically, the following check:
if (written <= 0 && size > 0)
seems redundant given the logic of the preceding loop.
To Reproduce
This is not a runtime bug but a logical issue identified through static analysis.
Relevant code:
long written = 0;
while (written < size) {
long count = fc.transferTo(written, size, newFc);
if (count <= 0) {
throw new IOException("Copying to new location " + rlocFile + " failed");
}
written += count;
}
Expected behavior
The condition after the loop should represent a reachable state.
However, based on the current logic:
- If size > 0, the loop executes at least once.
- If count <= 0, an exception is thrown immediately.
- Otherwise, written is incremented (written += count, with count > 0).
Therefore, after normal loop termination, written should always be greater than 0.
Screenshots
Not applicable.
Additional context
Given the loop semantics, the condition:
if (written <= 0 && size > 0)
appears to be unreachable.
This might be:
- a leftover defensive check, or
- redundant code that could be removed for clarity.
cc @gulyx
BUG REPORT
Describe the bug
While analyzing the implementation of FileInfo.moveToNewLocation, I noticed a condition that appears to be unreachable.
Specifically, the following check:
seems redundant given the logic of the preceding loop.
To Reproduce
This is not a runtime bug but a logical issue identified through static analysis.
Relevant code:
Expected behavior
The condition after the loop should represent a reachable state.
However, based on the current logic:
Therefore, after normal loop termination, written should always be greater than 0.
Screenshots
Not applicable.
Additional context
Given the loop semantics, the condition:
appears to be unreachable.
This might be:
cc @gulyx