gnodet-bot commented on code in PR #344:
URL:
https://github.com/apache/maven-clean-plugin/pull/344#discussion_r4087887260
##########
src/main/java/org/apache/maven/plugins/clean/Cleaner.java:
##########
@@ -282,7 +282,18 @@ public final void delete(@Nonnull Path basedir) throws
IOException {
var options = EnumSet.noneOf(FileVisitOption.class);
if (followSymlinks) {
options.add(FileVisitOption.FOLLOW_LINKS);
- basedir = getCanonicalPath(basedir, null);
+ try {
+ basedir = getCanonicalPath(basedir, null);
+ } catch (IOException e) {
+ /*
+ * Fall back to the original (unresolved) path. This can
happen on Windows Docker volumes
+ * where volume-mount reparse points cause toRealPath() to
throw NoSuchFileException
+ * (JDK-8172711). FOLLOW_LINKS is still set above so symlink
following still works via
+ * walkFileTree; the only loss is the loop-detection benefit
of canonicalization, which
+ * is benign in practice.
+ */
+ logger.debug("Could not resolve real path of \"" + basedir +
"\", continuing with original path: " + e);
Review Comment:
⚠️ **Stack trace lost on the error path.**
`logger.debug("..." + e)` calls `e.toString()` and embeds it as a plain
string, discarding the stack trace. When this actually fires on a Windows
Docker host — which is exactly the scenario you're trying to diagnose — the
stack trace is the most useful piece of information for understanding *which*
system call failed and why. Use the two-argument overload instead:
```suggestion
logger.debug("Could not resolve real path of \"" + basedir +
"\", continuing with original path", e);
```
--
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]
