jdx/mise · error

brew-cask: unsupported generic artifact type: {}

Error message

brew-cask: unsupported generic artifact type: {}

What it means

This error comes from the generic artifact copy routine: after handling the recognized artifact kinds (the `if` branches above, e.g. regular files with an explicit mode), the `else` branch rejects any other filesystem object type passed as a cask artifact. The library only supports copying artifact types it explicitly implements; anything else (directories, sockets, FIFOs, device nodes, or unrecognized artifact declarations) is refused rather than copied unsafely.

Source

Thrown at src/system/packages/brew/cask/mod.rs:1819

            copy_cask_artifact_at(&entry.path(), &fd, &entry.file_name())?;
        }
        nix::sys::stat::fchmod(&fd, mode)?;
    } else if metadata.is_file() {
        let destination = nix::fcntl::openat(
            parent,
            name,
            nix::fcntl::OFlag::O_WRONLY
                | nix::fcntl::OFlag::O_CREAT
                | nix::fcntl::OFlag::O_EXCL
                | nix::fcntl::OFlag::O_NOFOLLOW,
            nix::sys::stat::Mode::S_IRUSR | nix::sys::stat::Mode::S_IWUSR,
        )?;
        let mut source = std::fs::File::open(from)?;
        let mut destination = std::fs::File::from(destination);
        copy_file_contents(&mut source, &mut destination)?;
        nix::sys::stat::fchmod(&destination, mode)?;
    } else {
        bail!(
            "brew-cask: unsupported generic artifact type: {}",
            from.display()
        );
    }
    Ok(())
}

#[cfg(all(unix, target_os = "macos"))]
fn copy_file_contents(from: &mut std::fs::File, to: &mut std::fs::File) -> Result<()> {
    use std::os::fd::AsRawFd;

    // SAFETY: both descriptors remain open for the call and fcopyfile does not
    // retain them. A null state requests the default copyfile state.
    let result = unsafe {
        nix::libc::fcopyfile(
            from.as_raw_fd(),
            to.as_raw_fd(),
            std::ptr::null_mut(),

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Identify what `from` actually is (`ls -la` / `stat` on the printed path) and confirm which artifact type produced it.
  2. If the cask declares an artifact type this implementation lacks, use a cask variant whose artifacts are all supported kinds, or implement/handle that artifact type explicitly in the dispatcher instead of falling into the generic branch.
  3. If the source is corrupt leftover data (socket/FIFO), clean the staging area and re-download/re-extract the cask artifact.
  4. Re-run with a newer version of the library in case support for the artifact type was added upstream.

Example fix

// before: generic fallthrough for any path
} else {
    bail!("brew-cask: unsupported generic artifact type: {}", from.display());
}
// after: handle the type explicitly before the fallthrough
} else if metadata.is_dir() {
    copy_dir_recursively(from, destination, mode)?;
} else {
    bail!("brew-cask: unsupported generic artifact type: {}", from.display());
}
Defensive patterns

Strategy: validation

Validate before calling

use std::fs;
fn artifact_type_supported(from: &std::path::Path) -> bool {
    match fs::symlink_metadata(from) {
        Ok(md) => md.is_file(),
        Err(_) => false,
    }
}

Type guard

fn is_regular_file(p: &std::path::Path) -> bool {
    std::fs::symlink_metadata(p).map(|m| m.is_file()).unwrap_or(false)
}

Prevention

When it happens

Trigger: Invoking a cask install/artifact-staging path whose source `from` path is a filesystem object not matching any supported artifact branch — e.g. a directory, symlink, socket, or FIFO, or a cask artifact stanza mapping to an unsupported type — reaching the final `else` of the copy dispatcher.

Common situations: A cask's artifact list contains an entry type the implementation does not support (e.g. a `binary`/`preflight` style stanza routed into the generic copier); a staged artifact tree contains special files created by an upstream script; a partially-extracted archive left a socket or FIFO where a regular file was expected.

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


AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/9636ac01bb35efb4. Report an issue: GitHub.