Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

On macOS, files cp writes are not recorded as outputs, although fspy swaps cp for its bundled coreutils

オープン
#910 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
56/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
backend

調査の方向性

Start with crates/fspy_shared_unix/src/spawn/macos.rs and the linked COREUTILS_FUNCTIONS entry, then trace how the preload records filesystem reads and writes. Check interception coverage for clonefile, clonefileat, fclonefileat, and copyfile; reproduce with the cp task described in the issue. Done means copied destinations are recorded as outputs and restored on a cache hit.

索引モデルが issue の本文から書いたものです。

説明

Written by an AI agent (Claude) on behalf of @jasonkuhrt.

Problem

On macOS, a task that copies files into place with cp gets a cache entry without them, so a cache hit restores nothing.

fspy already swaps /bin/cp for its bundled coreutils so that copies can be tracked (spawn/macos.rs, COREUTILS_FUNCTIONS), and the swap does happen: inside vp run, cp --version prints cp (uutils coreutils) 0.4.0. But cp's writes still aren't recorded, while those of other swapped tools are.

Reproduction on vite-plus 1.4.0, macOS, APFS, with no remote cache:

// vite.config.ts
import { defineConfig } from 'vite-plus';

export default defineConfig({
  run: {
    tasks: {
      generate: {
        command: 'node generate.mjs',
        cache: { input: ['generate.mjs'] },
      },
    },
  },
});
// generate.mjs: makes a file in the OS temp folder, then copies it into place
import { mkdirSync, mkdtempSync, rmSync, writeFileSync } from 'node:fs';
import { execFileSync } from 'node:child_process';
import { tmpdir } from 'node:os';
import { join } from 'node:path';

const t = mkdtempSync(join(tmpdir(), 'gen-'));
writeFileSync(join(t, 'a.ts'), 'export const a = 1;\n');
rmSync('generated', { recursive: true, force: true });
mkdirSync('generated');
execFileSync('cp', [join(t, 'a.ts'), 'generated/a.ts']);
$ vp run generate        # generated/a.ts now exists
$ ls node_modules/.vite/task-cache/v18/*.tar.zst
ls: no matches found     # no output archive was stored
$ rm -rf generated
$ vp run generate
vp run: cache hit, 103ms saved.
$ ls generated
ls: generated: No such file or directory

The same task, with only the line that puts generated/a.ts in place changed:

How generated/a.ts gets there Recorded as output
fs.copyFileSync (Node) yes
sh -c 'cat "$0" > generated/a.ts' (swapped shell) yes
mkdir + touch (swapped coreutils) yes
Homebrew python3 shutil.copytree yes
cp src generated/a.ts (swapped coreutils) no
cp -R src_dir generated no
cp -R --reflink=never src_dir generated no

Cause

The swapped cp creates its destination with clonefile(src, dst, 0), which the preload doesn't intercept; std::fs::copy's fallback, fclonefileat, isn't intercepted either. Evidence and experiments: see the first comment.

Proposal

Record the source of the macOS clone and copy calls as a read and the destination as a write: clonefile, clonefileat, fclonefileat, and copyfile. That fixes the swapped cp, and any other tool that copies the same way.

Related: #908 (files renamed into place aren't recorded either).

主要言語
Rust
スター
480
フォーク
50
平均マージ
1日 5時間
マージ済み PR(30日)
63

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

voidzero-dev/vite-task のほかの issue

voidzero-dev/vite-task の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。