What causes "can't scan file %s: %w" in golangci/golangci-lint?

Fix or exclude the offending file: add it to lll's exclude paths or skip-dirs/skip-files so the scanner never reaches it.

golangci/golangci-lint · error

can't scan file %s: %w

Error message

can't scan file %s: %w

What it means

The lll (long line) linter scans files line-by-line with a bufio.Scanner. This error is returned when scanning a file fails for any reason other than a too-long line (or the line is too long but the configured max already exceeds bufio.MaxScanTokenSize, so it cannot be handled specially). It aborts analysis of that file with the underlying scanner error wrapped.

Source

Thrown at pkg/golinters/lll/lll.go:121

	if err := scanner.Err(); err != nil {
		// scanner.Scan() might fail if the line is longer than bufio.MaxScanTokenSize
		// In the case where the specified maxLineLen is smaller than bufio.MaxScanTokenSize
		// we can return this line as a long line instead of returning an error.
		// The reason for this change is that this case might happen with autogenerated files
		// The go-bindata tool for instance might generate a file with a very long line.
		// In this case, as it's an auto generated file, the warning returned by lll will
		// be ignored.
		// But if we return a linter error here, and this error happens for an autogenerated
		// file the error will be discarded (fine), but all the subsequent errors for lll will
		// be discarded for other files, and we'll miss legit error.
		if errors.Is(err, bufio.ErrTooLong) && maxLineLen < bufio.MaxScanTokenSize {
			pass.Report(analysis.Diagnostic{
				Pos:     ft.LineStart(goanalysis.AdjustPos(lineNumber, nonAdjPosition.Line, position.Line)),
				Message: fmt.Sprintf("line is more than %d characters", bufio.MaxScanTokenSize),
			})
		} else {
			return fmt.Errorf("can't scan file %s: %w", position.Filename, err)
		}
	}

	return nil
}

View on GitHub (pinned to ed7a235d2d)

Solutions

Fix or exclude the offending file: add it to lll's exclude paths or skip-dirs/skip-files so the scanner never reaches it.
If lines exceed 64KB, increase lll's max line length is not enough — instead pre-format/split the file or ignore it via //nolint:lll and file exclusion.
Re-run after confirming the file exists and is readable; check filesystem/permission errors reported in the wrapped %w cause.

Example fix

// .golangci.yml
// before
linters-settings:
  lll:
    line-length: 120
// after
linters-settings:
  lll:
    line-length: 120
    skip-files:
      - path/to/generated_huge_line.go

Defensive patterns

Strategy: validation

Validate before calling

info, err := os.Stat(path)
if err != nil || info.IsDir() { skip(path) } // ensure file readable before lint
f, err := os.Open(path); if err == nil { defer f.Close(); sc := bufio.NewScanner(f); if sc.Scan() && sc.Err() == bufio.ErrTooLong { skip(path) } }

Try / catch

if err := lllRun(...); err != nil {
    var wrapped interface{ Unwrap() error }
    if errors.As(err, &target) && errors.Is(target, bufio.ErrTooLong) {
        // treat as skip-file condition, not fatal
    }
}

Prevention

Exclude generated/minified files with huge single lines via skip-files.
Keep lll's line-length below bufio.MaxScanTokenSize (64KB) so the too-long-line path is handled gracefully.
Ensure files are not mutated/deleted while linting (avoid parallel build cleanup).

When it happens

Trigger: A file read/scan fails inside getLLLIssuesForFile: e.g. bufio.ErrTooLong on a line longer than bufio.MaxScanTokenSize (64KB) while lll's maxLineLen is >= that size, an I/O error reading the file, or a file deleted/changed between listing and scanning.

Common situations: Generated or minified files with single lines exceeding 64KB (e.g. huge JSON, lockfiles, embedded assets) checked by lll; symlinked or race-modified files during CI; network filesystem read errors.

Related errors

AI-assisted analysis of golangci/golangci-lint@ed7a235d2d (2026-09-02). Data as JSON: /api/errors/d68eb218521b86fd. Report an issue: GitHub.