nektos/act · error

Unable to os.Open: %v

Error message

Unable to os.Open: %v

What it means

Thrown by hashFiles() when streaming a matched file into the SHA-256 hasher fails (io.Copy error). Usually the read is interrupted: file truncated/removed mid-read, an I/O error on disk, or the file is a fifo that yields an error.

Source

Thrown at pkg/exprparser/functions.go:229

		if fi.IsDir() || !matcher.Match(parts, fi.IsDir()) {
			return nil
		}
		files = append(files, path)
		return nil
	}); err != nil {
		return "", fmt.Errorf("Unable to filepath.Walk: %v", err)
	}

	if len(files) == 0 {
		return "", nil
	}

	hasher := sha256.New()

	for _, file := range files {
		f, err := os.Open(file)
		if err != nil {
			return "", fmt.Errorf("Unable to os.Open: %v", err)
		}

		if _, err := io.Copy(hasher, f); err != nil {
			return "", fmt.Errorf("Unable to io.Copy: %v", err)
		}

		if err := f.Close(); err != nil {
			return "", fmt.Errorf("Unable to Close file: %v", err)
		}
	}

	return hex.EncodeToString(hasher.Sum(nil)), nil
}

func (impl *interperterImpl) getNeedsTransitive(job *model.Job) []string {
	needs := job.Needs()

	for _, need := range needs {

View on GitHub (pinned to 4f41128141)

Solutions

  1. Evaluate hashFiles before steps that mutate the hashed files (cache keys at step start).
  2. Exclude volatile directories from the pattern.
  3. Stabilize the source tree before hashing (stop dev servers).

Example fix

# before (hash while building)
- run: npm run build
- uses: actions/cache@v4
  with:
    key: ${{ hashFiles('dist/**') }}
# after (hash sources only)
- uses: actions/cache@v4
  with:
    key: ${{ hashFiles('src/**', 'package-lock.json') }}
- run: npm run build
Defensive patterns

Strategy: retry

Try / catch

var h string
for attempt := 0; attempt < 2; attempt++ {
  var err error
  h, err = hashFiles('src/**')
  if err == nil || !strings.Contains(err.Error(), 'io.Copy') { break }
  time.Sleep(100 * time.Millisecond) // file churned during read
}

Prevention

When it happens

Trigger: Concurrent writers truncating files while hashFiles evaluates; failing disks or NFS stale handles; matching named pipes created by dev servers.

Common situations: hashFiles computed while a watcher/dev process rewrites files; hashFiles inside a loop with a build step mutating outputs; container mounts with flaky I/O.

Related errors


AI-assisted analysis of nektos/act@4f41128141 (2026-08-15). Data as JSON: /api/errors/e90099072e2535da. Report an issue: GitHub.