oracle/graal · error · IOException

Error archiving %s. This directory will not be deleted and m

Error message

Error archiving %s. This directory will not be deleted and must be manually removed.

What it means

StandardPathUtilitiesProvider archives a diagnostic output directory into a zip when the dump quota/cleanup policy requires it. If zipping (walking the tree and writing the archive) throws IOException, the pending-deletion list is cleared and this IOException is thrown, explicitly warning that the source directory was kept and must be removed manually — a deliberate data-preserving failure mode.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/debug/StandardPathUtilitiesProvider.java:209

                            Files.copy(file, zos);
                            zos.closeEntry();
                        }
                        toDelete.add(file);
                        return FileVisitResult.CONTINUE;
                    }

                    @Override
                    public FileVisitResult postVisitDirectory(Path d, IOException exc) throws IOException {
                        toDelete.add(d);
                        return FileVisitResult.CONTINUE;
                    }
                });
                // Keep this in sync with the catch_files in ci/common.jsonnet
                TTY.println(DIAGNOSTIC_OUTPUT_DIRECTORY_MESSAGE_FORMAT, zipFile);
                return zipFile.getAbsolutePath();
            } catch (IOException e) {
                toDelete.clear();
                throw new IOException("Error archiving " + dir + ". This directory will not be deleted and must be manually removed.", e);
            } finally {
                if (!toDelete.isEmpty()) {
                    IOException lastDeletionError = null;
                    for (Path p : toDelete) {
                        try {
                            Files.delete(p);
                        } catch (IOException e) {
                            lastDeletionError = e;
                        }
                    }
                    if (lastDeletionError != null) {
                        throw new IOException("Error deleting " + dir + ". This is most likely due to a compilation on " +
                                        "another thread holding an open handle to a file within this directory. " +
                                        "Please delete the directory manually once the VM exits.", lastDeletionError);
                    }
                }
            }
        }

View on GitHub (pinned to a66e9ccd1d)

Solutions

Follow the message: manually remove the named directory once you have extracted anything you need from it.
Free disk space and check permissions on the dump root so archive writing can succeed next time.
Reduce dump volume (-Dgraal.DumpPath to a bigger volume, lower dump level, or disable dumping) so the archival quota path is not hit.
If files are being consumed by concurrent compilations, stagger runs or give each run its own DumpPath subdirectory.

Defensive patterns

Strategy: try-catch

Try / catch

try {
    String archived = provider.cleanupAndArchiveOutputs(dir);
} catch (IOException e) {
    if (e.getMessage().startsWith("Error archiving")) {
        // directory was intentionally preserved; schedule manual cleanup after VM exit
        pendingManualCleanup.add(dir);
    } else {
        throw e;
    }
}

Prevention

Keep dump volumes below quota by purging old dump roots on a schedule.
Give concurrent runs separate DumpPath directories so archival never races with live writers.

When it happens

Trigger: Calling the provider's cleanup/archive path (triggered by Graal debug dumping when accumulated output directories exceed configured limits) while the filesystem prevents reading files or writing the zip: files deleted concurrently, permission changes, disk full, or a read-only output volume.

Common situations: Long-running builds/daemons producing many dump directories on a full disk; parallel compilations racing on shared dump directories; containers where the dump mount is read-only or overlay-limited. The directory intentionally survives so evidence is not destroyed.

Related errors

AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14). Data as JSON: /api/errors/19394431cfdf559c. Report an issue: GitHub.