CanonicalFileUtils.java.. and . path components, and normalizes path separators via File.getCanonicalPath(). Handles I/O errors gracefully by falling back to getAbsolutePath(). Provides both string-based and File-object-based overloads for path resolution. Used wherever ProjectForge needs to compare file paths or ensure consistent path representation.java.io.File — JDK file abstractionjava.io.IOException — Checked exception from getCanonicalPath()org.slf4j.Logger — Error logging for I/O failuresReturns the canonical path of a file as a String. If getCanonicalPath() throws IOException (e.g., the file doesn't exist and the filesystem can't resolve its canonical form), falls back to getAbsolutePath() and logs the error.
Same logic but returns a File object via getCanonicalFile() / getAbsoluteFile().
Convenience overload that wraps a string path in new File(path) and delegates to absolute(File).
Java's File.getCanonicalPath() provides several guarantees that getAbsolutePath() does not:
. (current directory) and .. (parent directory) are resolved// is collapsedThis is critical for security-sensitive operations where paths from user input must be compared against allowed paths — two different string representations might refer to the same file (e.g., /home/user/../user/file and /home/user/file).
The class uses a graceful degradation pattern: if canonical resolution fails (IOException), it falls back to absolute path and logs the error. This is important because getCanonicalPath() can throw IOException for reasons beyond the application's control (e.g., filesystem permissions, NFS mount issues, or the file not existing). The fallback ensures the application continues to function, albeit with a potentially non-normalized path.
All methods handle null input gracefully — returning null without throwing NullPointerException. This simplifies caller code by eliminating the need for null checks before calling the utility.
CanonicalFileUtils is used in scenarios such as:
.. traversalInternal error while trying to get canonical path" is slightly misleading — an IOException from getCanonicalPath() is not necessarily an "internal error" but often an environmental condition (missing file, permission denied). The fallback to getAbsolutePath() silently accepts a potentially un-normalized path.FileHelper class. This follows the Single Responsibility Principle, keeping utilities focused and testable.868d6abb7 2025 -> 2026 63081666f Source file headers: 2024-> 2025. b6092df09 Copyright 2023 -> 2024 ab45d51fa Copyright 2001-2022 -> 2001-2023. 5f7ef41b8 Copyright 2021 -> 2022 ceb63e8a1 Source code header: (C) 2001-2021. 7c79f1922 Copyright of source header -> 2020. bd25a85fb WIP: Setup wizard (Swing and Lanterna)