Idea: LIST/GLOB — enumerate guest files without shelling out
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Start by reading the existing message set and follow-up issue #72 before deciding whether this belongs in a new RPC or an optional surface. The work would include the proto, guest implementation, and an e2e test; done means single-directory listing supports optional globbing, deterministic name ordering, pagination, and the specified file metadata.
索引モデルが issue の本文から書いたものです。
説明
Problem
There is no primitive for directory enumeration on the guest filesystem. Clients that need to discover files must either exec a shell (ls/find), which couples clients to guest shell semantics and bypasses structured errors and accounting, or maintain client-side ledgers that drift from actual filesystem state.
Follow-up from #72: append makes segmented, append-only logs viable inside guests; enumeration is the complementary half of that workload. Our concrete case: agents write rotating segment files (seg.0.jsonl, seg.1.jsonl, …), and a host-side poller needs to enumerate segments it hasn't read. This generalizes to checkpoint discovery, temp-file cleanup passes, and any "what exists in this directory" query.
Proposal
Additive RPC (or an optional surface on the existing message set), single-directory scope for v1:
message ListFilesRequest {
string path = 1; // directory to list
string pattern = 2; // optional glob, e.g. "seg.*.jsonl"
int32 limit = 3; // page size
string page_token = 4;
}
message ListFilesResponse {
repeated FileEntry entries = 1;
string next_page_token = 2;
}
message FileEntry {
string name = 1;
int64 size = 2;
google.protobuf.Timestamp modified = 3;
uint32 mode = 4;
}
- Deterministic ordering: entries sorted by name.
- Pagination (
limit/page_token) keeps large directories bounded. - Out of scope for v1: recursive walks; streaming/watch semantics — the fuller long-term answer for tailing workloads, but a substantially larger surface, worth discussing separately.
Alternatives considered
- Exec
find/lsin the guest — rejected: shell coupling, unstructured output and errors, no accounting. - Client-side segment ledgers — rejected: duplicate directory state, drifts from the filesystem, and must be reimplemented in every client.
ReadFileon directories — not meaningful under current read semantics; would overload the read path.
If this fits the project's direction, I'm glad to draft the PR — proto + guest implementation + e2e test, same shape as #72.
- 主要言語
- Go
- スター
- 70
- フォーク
- 17
- 平均マージ
- 21時間 36分
- マージ済み PR（30日）
- 19
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
agent-substrate/env のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
agent-substrate/env#123 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 74/100
agent-substrate/env#121 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
agent-substrate/env#119 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
agent-substrate/env#118 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 57/100
agent-substrate/env#117 ·
メンテナーはふだん 1 日以内に返信
agent-substrate/env の issue をすべて見る
似ている issue
-
needs-area
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Azure/typespec-azure#5936 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 70/100
-
Fix mode unpins a reusable workflow call when the same repository is also used as a step actionオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
github/gh-actions-lock#261 ·
メンテナーはふだん 1 日以内に返信
-
bug documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
labmonkeys-space/nl6#974 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100