What causes "Unable to delete temporary file: {listFile.getAbsolutePath()}" in NationalSecurityAgency/ghidra?

Ensure all FileWriter and file handles are properly closed (use try-with-resources) before cleanup runs.

NationalSecurityAgency/ghidra · warning · IOException

Unable to delete temporary file: {listFile.getAbsolutePath()

Error message

Unable to delete temporary file: {listFile.getAbsolutePath()}

What it means

Thrown by deleteTemporaryDirectory when an individual file within the temp directory cannot be deleted (listFile.delete() returns false). File.delete() fails when the file is locked, the process lacks permission, or the file is in use. The exception aborts cleanup, potentially leaving remaining files and the directory behind.

Source

Thrown at Ghidra/Features/BSim/src/main/java/ghidra/features/bsim/query/ingest/BulkSignatures.java:1050

		else if (dir.isDirectory() == false) {
			throw new IOException(dir.getAbsolutePath() + ": is not a directory");
		}
		dir = dir.getCanonicalFile();
		return dir;
	}

	private void deleteTemporaryDirectory(File tempDir) throws IOException {
		if (!tempDir.exists()) {
			return;
		}
		File[] listFiles = tempDir.listFiles();
		if (listFiles == null) {
			throw new IOException(
				"Could not list files in temp directory: " + tempDir.getAbsolutePath());
		}
		for (File listFile : listFiles) {
			if (!listFile.delete()) {
				throw new IOException(
					"Unable to delete temporary file: " + listFile.getAbsolutePath());
			}
		}
		if (!tempDir.delete()) {
			throw new IOException("Unable to delete temp directory: " + tempDir.getAbsolutePath());
		}
	}

	private class UpdateRepository extends IterateRepository {
		private File outdirectory;
		private String repo;
		private boolean overwrite;
		private DatabaseInformation info;
		private LSHVectorFactory vectorFactory;

		public UpdateRepository(File outdir, String rp, boolean owrite, DatabaseInformation i,
				LSHVectorFactory vFactory) {
			outdirectory = outdir;

View on GitHub (pinned to d5f144c24d)

Solutions

Ensure all FileWriter and file handles are properly closed (use try-with-resources) before cleanup runs.
Run cleanup with the same user that created the files.
On Windows, disable or exclude the temp directory from antivirus scanning.
Make cleanup best-effort: catch and log individual file deletion failures rather than aborting.

Example fix

// before
for (File listFile : listFiles) {
    if (!listFile.delete()) {
        throw new IOException("Unable to delete temporary file: " + listFile.getAbsolutePath());
    }
}

// after — best-effort, collect failures
List<String> failed = new ArrayList<>();
for (File listFile : listFiles) {
    if (!listFile.delete()) {
        failed.add(listFile.getAbsolutePath());
    }
}
if (!failed.isEmpty()) {
    Msg.warn(this, "Could not delete " + failed.size() + " temp files: " + failed);
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Ensure all file handles are closed before cleanup
// Use try-with-resources for all FileWriter/FileInputStream operations
try (FileWriter w = new FileWriter(file)) {
    manager.saveXml(w);
} // handle closed here, safe to delete afterward

Type guard

// No type guard — this is a runtime file-lock issue.
// Best prevention is ensuring handles are closed.

Try / catch

// Best-effort file deletion — don't abort on individual file failures
for (File listFile : listFiles) {
    if (!listFile.delete()) {
        Msg.warn(this, "Could not delete: " + listFile.getAbsolutePath());
        // System.gc() may help release handles on some JVMs
    }
}

Prevention

Always use try-with-resources to close file handles before cleanup.
Ensure no concurrent process holds locks on temp files.
On Windows, exclude the temp directory from antivirus scanning.
Treat individual file deletion as best-effort during cleanup.

When it happens

Trigger: A file inside the temp directory is still open or locked by another process or thread when deleteTemporaryDirectory tries to clean up. On Windows, this is common when a FileWriter or other handle hasn't been closed. On Unix, it can be a permission issue.

Common situations: A prior FileWriter was not closed properly (leaked handle) and the OS still holds the file open; another BSim thread or process is reading the file; antivirus or backup software scanning the temp directory on Windows; the file was created by a process running as a different user.

Related errors

AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14). Data as JSON: /api/errors/4d1044a80c3daf3e. Report an issue: GitHub.