AlistGo/alist · error · ErrExtractSizeExceeded

total size of decompressed files exceeds the limit

Error message

total size of decompressed files exceeds the limit

What it means

ErrExtractSizeExceeded is returned by internal/archive/tool's SizeLimiter when the cumulative bytes written by one decompression task would exceed the configured max (a non-positive max disables the limit). It is a decompression-bomb mitigation: extraction stops as soon as the remaining budget would go negative.

Source

Thrown at internal/archive/tool/limiter.go:9

package tool

import (
	"errors"
	"io"
	"sync/atomic"
)

var ErrExtractSizeExceeded = errors.New("total size of decompressed files exceeds the limit")

// SizeLimiter limits the total bytes written by one decompress task.
// A non-positive max means no limit.
type SizeLimiter struct {
	remain  int64
	limited bool
}

func NewSizeLimiter(max int64) *SizeLimiter {
	if max <= 0 {
		return &SizeLimiter{}
	}
	return &SizeLimiter{remain: max, limited: true}
}

func (l *SizeLimiter) WrapWriter(w io.Writer) io.Writer {
	if l == nil || !l.limited {
		return w

View on GitHub (pinned to 843d9dc814)

Solutions

Raise the decompression size limit in settings if the archive is trusted and legitimately large
Scan/inspect the archive (list entries and sizes) before extracting — a 10KB file claiming 500GB is a bomb
Verify the limit's unit (bytes vs MiB) in your configuration
Reject or quarantine the archive if it is untrusted and keeps tripping the limit

Example fix

// before
limiter := tool.NewSizeLimiter(1024) // accidental 1KB cap

// after
limiter := tool.NewSizeLimiter(10 << 30) // 10GiB cap

Defensive patterns

Strategy: validation

Validate before calling

var total int64
for _, h := range archive.Headers() { total += h.Size }
if limiterMax > 0 && total > limiterMax { return tool.ErrExtractSizeExceeded }

Type guard

func isSizeExceeded(err error) bool { return errors.Is(err, tool.ErrExtractSizeExceeded) }

Try / catch

err := extractor.Extract(ctx, archive, limiter)
if errors.Is(err, tool.ErrExtractSizeExceeded) {
    // do not retry blindly: either raise the cap for trusted archives or reject
    return rejectOrEscalate(archive)
}

Prevention

List entries and sum declared sizes before extracting
Set caps in unambiguous units (bytes) and document them
Treat limit trips on untrusted uploads as security events, not bugs

When it happens

Trigger: Extracting an archive whose expanded content exceeds the configured size cap — including malicious zip/gzip bombs where a tiny archive expands to hundreds of GB, or merely a legitimately large archive against a low cap. Any writer wrapped by SizeLimiter during archive extraction can trigger it once remain drops below the incoming write size.

Common situations: Default extraction limits set lower than the archives users actually upload; a hostile upload containing a compression bomb; nested archives that expand recursively; caps configured in bytes vs MB confusion (e.g. 100 interpreted as 100 bytes).

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/5bebc104a2e26777. Report an issue: GitHub.