jdx/mise · error
unsupported task cache archive entry type
Error message
unsupported task cache archive entry type
What it means
While converting a downloaded task-cache archive into the content-addressable store (CAS), archive_to_cas walks each archive entry and maps it to an ArchiveNode (file, directory, or symlink). If an entry's type is none of these (e.g. hardlink, fifo, device node, or other exotic tar entry kinds), it cannot be represented, so mise bails. This guards the CAS from storing entries it cannot later restore faithfully.
Solutions
- Repackage the cache archive so it contains only regular files, directories, and symlinks (e.g. tar without --hard-dereference, no device/fifo entries).
- Identify which entry has the unsupported type (inspect with `tar -tvf archive.tar`) and remove or convert it.
- Regenerate the cache by re-running the task so mise builds the archive itself from real filesystem contents.
- If the producer legitimately needs hardlinks, switch it to emit regular files or symlinks instead.
Example fix
// before: producer emits hardlinks tar -cf cache.tar --hard-dereference=no dir // after: dereference everything into plain files tar -cf cache.tar --hard-dereference dir
Defensive patterns
Strategy: validation
Validate before calling
const OK = new Set(['file', 'dir', 'symlink']);
const bad = entries.filter(e => !OK.has(e.type));
if (bad.length) throw new Error(`unsupported entry types: ${bad.map(e => e.path)}`); Type guard
const isSupportedEntry = (e) => ['file','dir','symlink'].includes(e.type);
Prevention
- Build cache archives with only files, directories, and symlinks.
- Avoid tar options that emit hardlinks/device nodes (e.g. don't archive /dev or sockets).
- Inspect producer output with `tar -tvf` before uploading.
When it happens
Trigger: Restoring/committing a remote task cache archive produced by a tool that emitted entry kinds other than regular files, directories, and symlinks — e.g. tar archives containing hardlinks, block/char devices, or FIFOs.
Common situations: A custom or third-party cache-packaging step created the archive with unusual entry types; a cache archive was hand-crafted or generated on a platform that records device nodes; archives tampered with or corrupted in transit.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- task cache archive contains duplicate paths
- invalid remote task cache key
- path must identify an output beneath the task directory
- path must not escape the task directory
- remote cache directory contains duplicate names
AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17).
Data as JSON: /api/errors/d3a32fe7a00333ce.
Report an issue: GitHub.
Appendix: source
Thrown at src/task/task_cache_store.rs:610
digest: CacheDigest {
algorithm: "blake3".into(),
hash: hasher.finalize().to_hex().to_string(),
size,
},
executable: mode & 0o111 != 0,
mode,
file: temporary,
}
} else if entry_type == EntryType::Symlink {
let target = entry
.header()
.link_name()
.ok_or_else(|| eyre!("remote cache symlink is missing its target"))?
.into_owned();
validate_cache_symlink_target(&entry_path, &target)?;
ArchiveNode::Symlink { mode, target }
} else {
bail!("unsupported task cache archive entry type");
};
if nodes.insert(entry_path.clone(), node).is_some() {
bail!("task cache archive contains duplicate paths");
}
let mut parent = entry_path.parent();
while let Some(path) = parent {
nodes
.entry(path.to_path_buf())
.or_insert(ArchiveNode::Directory { mode: 0o755 });
parent = path.parent();
}
}
fn build_directory(
path: &Path,
nodes: &BTreeMap<PathBuf, ArchiveNode>,
directory_uploads: &mut Vec<BlobUpload>,
) -> Result<CacheDigest> {View on GitHub (pinned to 533346cc37)