jenkinsci/jenkins · critical · IOException
Failed to obtain file from path ${dir}
Error message
Failed to obtain file from path ${dir} What it means
Thrown after Files.createTempDirectory succeeds but the resulting Path's toFile() returns null (which is technically impossible per the Java spec for valid Path objects backed by the default filesystem). The check is a defensive/dead-code guard — if you hit this, it indicates a custom FileSystem provider is returning a Path whose toFile() contract is violated, or memory/filesystem corruption. In practice this exception is unreachable under normal JRE usage.
Source
Thrown at core/src/main/java/hudson/FilePath.java:1744
}
private static final long serialVersionUID = 1L;
@Override
public String invoke(File dir, VirtualChannel channel) throws IOException {
Path tempPath;
final boolean isPosix = FileSystems.getDefault().supportedFileAttributeViews().contains("posix");
if (isPosix) {
tempPath = Files.createTempDirectory(Util.fileToPath(dir), name,
PosixFilePermissions.asFileAttribute(EnumSet.allOf(PosixFilePermission.class)));
} else {
tempPath = Files.createTempDirectory(Util.fileToPath(dir), name);
}
if (tempPath.toFile() == null) {
throw new IOException("Failed to obtain file from path " + dir);
}
return tempPath.toFile().getName();
}
}
/**
* Deletes this file.
* @return true, for a modicum of compatibility
* @throws IOException if it exists but could not be successfully deleted
*/
public boolean delete() throws IOException, InterruptedException {
act(new Delete());
return true;
}
private static class Delete extends MasterToSlaveFileCallable<Void> {
private static final long serialVersionUID = 1L;
View on GitHub (pinned to 2e228ff40b)
Solutions
- Verify no custom FileSystem provider is being injected via -Djava.nio.file.spi.DefaultFileSystemProvider or META-INF services.
- If using an in-memory filesystem (e.g., Jimfs), switch FilePath operations to a real temp directory backed by the OS filesystem.
- Treat this as a JVM/filesystem bug — report the provider implementation that returns null from Path.toFile().
Example fix
// The guard is dead code; if hit, the root cause is the FileSystem provider. // No application-level fix. Verify the default provider: System.err.println(FileSystems.getDefault().provider().getClass());
Defensive patterns
Strategy: try-catch
Validate before calling
// Unreachable in practice; verify the default FileSystem provider
if (!FileSystems.getDefault().provider().getClass().getName().contains("sun")) {
LOGGER.warning("Non-standard default FileSystem provider detected; FilePath temp dir creation may fail.");
} Try / catch
try {
String tmpName = filePath.createTempDir(prefix);
} catch (IOException e) {
if (e.getMessage().contains("Failed to obtain file from path")) {
// Investigate FileSystem provider; this should not happen on standard JVMs
throw new IllegalStateException("Filesystem provider returned null Path.toFile()", e);
}
throw e;
} Prevention
- Do not register custom DefaultFileSystemProvider implementations that return non-file-backed Paths.
- Avoid using in-memory filesystems (Jimfs) for FilePath operations that rely on java.io.File.
When it happens
Trigger: Calling FilePath.createTempDir() variants that delegate to Files.createTempDirectory on a system where the default FileSystem provider does not map to java.io.File. Only reachable if a custom FileSystem is registered as the default and returns non-file-backed Paths.
Common situations: Effectively never hit on standard JVM/JDK installations. Theoretical: running inside a test harness or container that replaces the default FileSystem provider, or a Jimfs/in-memory filesystem that doesn't implement toFile().
Related errors
- Failed to load {}. The file does not exist
- Failed to load {}. It is not a file
- Failed to install ${archive} to ${remote}
- Failed to mkdirs: ${remote}
- Failed to create a temp file on ${remote}
AI-assisted analysis of jenkinsci/jenkins@2e228ff40b (2026-08-14).
Data as JSON: /api/errors/8cd543d84a1aac80.
Report an issue: GitHub.