balodesecurity opened a new pull request, #8322:
URL: https://github.com/apache/hadoop/pull/8322

   ## Summary
   
   `DistributedFileSystem.getFileChecksum()` on an empty (zero-byte) file 
always returned an `MD5MD5CRC32GzipFileChecksum` value, even when the client 
was configured with `dfs.checksum.combine.mode=COMPOSITE_CRC`. This was 
misleading and inconsistent with what non-empty files return in the same mode.
   
   ### Root Cause
   In `FileChecksumHelper.FileChecksumComputer.compute()`, the empty-file fast 
path unconditionally constructed an `MD5MD5CRC32GzipFileChecksum` without 
checking `combineMode`.
   
   ### Fix
   Check `combineMode` in the empty-file path:
   - **`COMPOSITE_CRC`**: return `CompositeCrcFileChecksum(crc=0, 
configuredChecksumType, configuredBytesPerCrc)` using the client's configured 
`ChecksumOpt`.
   - **`MD5MD5CRC`**: retain the existing backward-compatible magic value 
(`MD5MD5CRC32GzipFileChecksum(0, 0, md5OfZeros)`) to avoid breaking existing 
tools.
   
   ### Changes
   - `FileChecksumHelper.java`: split the empty-file branch on `combineMode`.
   - `TestGetFileChecksum.java`: add `testEmptyFileChecksumType` verifying both 
modes return the expected `FileChecksum` subclass for a zero-byte file.
   
   ## Test plan
   - [ ] `TestGetFileChecksum#testEmptyFileChecksumType` passes locally ✅
   - [ ] Full module build passes (`mvn package ... -DskipTests`) ✅


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to