unslothai/unsloth · error · RuntimeError

The pinned {spec.name} archive has too many entries

Error message

The pinned {spec.name} archive has too many entries

What it means

Streaming extraction counts tar members; once member_count exceeds _ARCHIVE_MAX_MEMBERS the archive is rejected. This caps filesystem-inode and CPU exhaustion from archives with millions of tiny entries (a classic tar DoS shape) and bounds the extraction loop.

Source

Thrown at studio/backend/utils/third_party_source.py:650

        raise RuntimeError(f"The pinned {spec.name} source archive is not configured")
    workspace = Path(tempfile.mkdtemp(prefix = ".archive-", dir = destination.parent))
    archive = workspace / "source.tar.gz"
    staging = workspace / "source"
    staging.mkdir()
    try:
        _download_archive(spec.archive_url, archive, spec)
        member_count = 0
        uncompressed_bytes = 0
        extracted = set()
        try:
            with archive.open("rb") as compressed:
                with gzip.GzipFile(fileobj = compressed, mode = "rb") as decompressed:
                    reader = _BoundedArchiveReader(decompressed, _ARCHIVE_MAX_TAR_BYTES)
                    with tarfile.open(fileobj = reader, mode = "r|") as bundle:
                        for member in bundle:
                            member_count += 1
                            if member_count > _ARCHIVE_MAX_MEMBERS:
                                raise RuntimeError(
                                    f"The pinned {spec.name} archive has too many entries"
                                )
                            parts = _archive_member_parts(member, spec)
                            if member.isdir():
                                continue
                            if not member.isfile() or member.size < 0:
                                raise RuntimeError(
                                    f"The pinned {spec.name} archive contains a non-regular file"
                                )
                            uncompressed_bytes += member.size
                            if uncompressed_bytes > _ARCHIVE_MAX_UNCOMPRESSED_BYTES:
                                raise RuntimeError(
                                    f"The pinned {spec.name} archive expands too large"
                                )
                            if len(parts) < 3 or parts[1] != spec.package:
                                continue
                            relative = "/".join(parts[1:])
                            _package_path_parts(relative, spec, kind = "archive")

View on GitHub (pinned to 203007d190)

Solutions

  1. Count entries: tar -tzf source.tar.gz | wc -l and compare with _ARCHIVE_MAX_MEMBERS
  2. Repin to a trimmed export containing only the package subtree (the installer only extracts parts[1] == spec.package anyway)
  3. If the count is legitimate, raise _ARCHIVE_MAX_MEMBERS in your build with awareness of disk/inode impact
  4. Verify the artifact digest against the pin to rule out tampering
Defensive patterns

Strategy: validation

Validate before calling

import tarfile
with tarfile.open("source.tar.gz") as tf:
    count = sum(1 for _ in tf)
assert count <= _ARCHIVE_MAX_MEMBERS, f"{count} entries exceeds cap"

Try / catch

try:
    ensure_pinned_source(spec)
except RuntimeError as e:
    if "too many entries" in str(e):
        # switch to a trimmed subtree export rather than raising the member cap blindly

Prevention

When it happens

Trigger: Iterating bundle members in _install_archive_source when the tarball contains more entries than _ARCHIVE_MAX_MEMBERS — either a maliciously generated high-entry-count archive or an unusually large legitimate monorepo snapshot.

Common situations: Pinning a huge monorepo's full snapshot instead of a subdirectory export; generated archives containing per-file node_modules-like trees; hostile archive crafted to exhaust inodes.

Related errors

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/4ee19acd4cc9b33b. Report an issue: GitHub.