pjfanning opened a new pull request, #1249: URL: https://github.com/apache/poi/pull/1249
`MAPIMessage(File)` and `MAPIMessage(String)` open a file-backed `POIFSFileSystem` and hand it to `MAPIMessage(POIFSFileSystem)`, which delegates to `MAPIMessage(DirectoryNode)`. That constructor runs `POIFSChunkParser.parse` and the chunk sorters with no cleanup, so a malformed `.msg` file leaks the `RandomAccessFile` behind the filesystem. `MAPIMessage(File)` is the constructor the javadoc recommends for lower memory use, so this is the path most likely to be hit. ### Fix `MAPIMessage(POIFSFileSystem)` already takes ownership of the filesystem — `close()` closes it via `POIDocument.close()` — so it is also the right place to close it when construction does not complete. The chunk parsing moves into a private `parseChunks` method, and `MAPIMessage(POIFSFileSystem)` now calls `super`/`parseChunks` directly instead of delegating with `this(fs.getRoot())`, so the parse can be wrapped in a try/catch. The original exception is rethrown unchanged. `MAPIMessage(DirectoryNode)` deliberately keeps no cleanup: it is used for messages embedded in a filesystem owned by someone else (`AttachmentChunks.getEmbeddedMessage()`), so closing that filesystem there would be wrong. `HSLFSlideShowImpl` solves the same problem the same way, at `HSLFSlideShowImpl.java:262`. No public signatures change, so there is nothing for MiMa to check. The 18 `org.apache.poi.hsmf.*` test classes pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
