quarkusio/quarkus · error · RuntimeException

Unable to get last modified time for

Error message

Unable to get last modified time for 

What it means

While building a Jib file-entries layer, Quarkus tries Files.getLastModifiedTime(sourcePath) to compute each file's modification time (for reproducible builds it normally uses a forced time, but when none applies it reads the real mtime). If the file disappears or is unreadable mid-build, the IOException is wrapped in RuntimeException("Unable to get last modified time for " + sourcePath).

Source

Thrown at extensions/container-image/container-image-jib/deployment/src/main/java/io/quarkus/container/image/jib/deployment/JibProcessor.java:705

    public JibContainerBuilder addLayer(JibContainerBuilder jibContainerBuilder, List<Path> files,
            AbsoluteUnixPath pathInContainer, String name, boolean isMutableJar,
            boolean enforceModificationTime, Instant forcedModificationTime)
            throws IOException {
        FileEntriesLayer.Builder layerConfigurationBuilder = FileEntriesLayer.builder().setName(name);

        for (Path file : files) {
            layerConfigurationBuilder.addEntryRecursive(
                    file, pathInContainer.resolve(file.getFileName()),
                    isMutableJar ? REMOTE_DEV_FOLDER_PERMISSIONS_PROVIDER : DEFAULT_FILE_PERMISSIONS_PROVIDER,
                    (sourcePath, destinationPath) -> {
                        if (enforceModificationTime) {
                            return forcedModificationTime;
                        }

                        try {
                            return Files.getLastModifiedTime(sourcePath).toInstant();
                        } catch (IOException e) {
                            throw new RuntimeException("Unable to get last modified time for " + sourcePath, e);
                        }
                    },
                    isMutableJar ? REMOTE_DEV_OWNERSHIP_PROVIDER : DEFAULT_OWNERSHIP_PROVIDER);
        }

        return jibContainerBuilder.addFileEntriesLayer(layerConfigurationBuilder.build());
    }

    private void mayInheritEntrypoint(JibContainerBuilder jibContainerBuilder, List<String> entrypoint,
            List<String> arguments) {
        if (entrypoint.size() == 1 && "INHERIT".equals(entrypoint.get(0))) {
            jibContainerBuilder
                    .setEntrypoint((List<String>) null)
                    .setProgramArguments(arguments);
        }
    }

    private List<String> determineEffectiveJvmArguments(ContainerImageJibConfig jibConfig,

View on GitHub (pinned to e1c734241f)

Solutions

1. Re-run the build without concurrent processes touching target/ (stop dev mode, other builds, CI races)
2. Run mvn clean first so the fast-jar output is rebuilt atomically before the container step
3. Check for broken symlinks or unreadable files in target/quarkus-app (find target/quarkus-app -xtype l)
4. Avoid building images from NFS/network mounts; build locally or on stable storage

Example fix

// before: image build races with dev mode on the same project
$ quarkus dev &  mvn package -Dquarkus.container-image.build=true
// after: stop dev mode, clean, then build
$ mvn clean package -Dquarkus.container-image.build=true

// verify the packaged app tree is stable and sane before the container step
java.nio.file.Path appDir = java.nio.file.Path.of("target/quarkus-app");
if (!java.nio.file.Files.isDirectory(appDir)) throw new IllegalStateException("Run package first: missing " + appDir);
try (var s = java.nio.file.Files.walk(appDir)) {
    var broken = s.filter(java.nio.file.Files::exists == null ? p -> false :
            p -> java.nio.file.Files.isSymbolicLink(p) && !java.nio.file.Files.exists(p)).count();
    if (broken > 0) throw new IllegalStateException(broken + " broken symlinks in quarkus-app");
}

When it happens

Trigger: A file in the fast-JAR (or mutable-jar) output directory that Jib is packaging is deleted or becomes unreadable between directory scanning and mtime lookup — typically a concurrently rebuilt target/ directory, or a symlink/broken file in the packaged paths.

Common situations: Running a container build while another process (IDE, another Maven build, spring-boot-devtools-like watcher) cleans target/; building from a shared/network filesystem with flaky stat; broken symlinks inside lib/ or app/ directories.

Related errors

• Unable to add extra files in
• Buildpack build unable to verify project dir
• Unable to save enhanced Dockerfile contents to disk
• The native binary produced by the build is not a Linux binar
• Unable to create container image

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/30fc182790021b00. Report an issue: GitHub.