본문으로 건너뛰기
토파즈6.0 · 출시 전
다운로드 →

문서 검색

명세 6.0

방향키로 결과를 고르고 Enter를 눌러 여세요.

API 이름, 진단 번호, 규칙 또는 프로젝트 주제를 입력하세요.

    도구

    storage clean

    Removes inactive temporary workspaces owned by Topaz.

    Invocation, options and results

    링크

    topaz storage clean

    호출 형식
    1. topaz storage clean

    입력

    Use topaz storage clean with no operands or options. Reject a path operand, root override, compiler or language selector, output format selector and every extra argument before any deletion.

    Use the managed build root selected by the same environment precedence as storage status. An environment selected root does not grant authority over unmarked directories.

    옵션과 충돌

    옵션기본값계약충돌

    출력 채널

    stdout

    stderr

    종료 상태

    0

    All eligible removals complete, including when no workspace is eligible.

    1

    Command arguments, managed storage inspection or an eligible deletion fails. Earlier completed removals remain completed.

    효과

    Require a real child directory with a valid regular .topaz-workspace.json marker using topaz.storage.workspace.v1. Skip unowned paths, invalid markers, symlinked workspaces and symlinked markers.

    Remove a directory only after the owner is confirmed inactive. A live owner remains protected after 24 hours. Retain the directory when liveness is uncertain. Revalidate the marker and owner state immediately before deleting.

    Delete only the selected owned subtree and do not follow nested symlinks outside it. A concurrent disappearance is harmless. Do not change files in retained workspaces or delete caller source, package output or arbitrary directories.

    Perform no network access. Local process inspection does not authorize contacting a remote host.

    Cleanup is state dependent and changes the input state. A second run after a successful cleanup reports zero additional removals unless another eligible workspace appears.

    With an identical managed storage snapshot and liveness observations, the same paths are eligible and processed in the same order. Creation time alone never makes a live owner eligible.

    Cleanup does not read or rewrite the current package manifest or lock and does not remove its vendored dependencies. Package locks and compiler workspace ownership markers are different records.

    Do not run dependency resolution or materialization to decide which workspaces are owned.

    Operation

    링크

    Review storage status before cleanup. The cleanup contract preserves live or uncertain owners.

    Example contract

    링크
    규칙tools-commands-storage-clean.rule.invocation

    Example contract

    The invocation topaz storage clean main.tpz --language-version 5.21 is expected to exit with 1.

    Reject the adapter-supplied extra positional operand before listing or removing any workspace. The current dispatcher falls back to an unknown-command error for the storage family.

    이유

    Cleanup selects inactive workspaces owned by Topaz. Rejecting a path operand prevents it from being treated as authority to delete an arbitrary user path.

    Behavior contract

    링크
    규칙tools-commands-storage-clean.rule.behavior

    Command behavior

    Arguments and rejection

    Use topaz storage clean with no operands or options. Reject a path operand, root override, compiler or language selector, output format selector and every extra argument before any deletion.

    Use the managed build root selected by the same environment precedence as storage status. An environment selected root does not grant authority over unmarked directories.

    Output

    Write a human line for each removed owned workspace. On successful completion, write the removed workspace count and reclaimed byte count. Process eligible paths in deterministic path order.

    Retained active or uncertain workspaces do not count as removed or reclaimed. When no workspace is eligible, write a zero removal summary and succeed.

    Write inspection or deletion failures to standard error. There is no JSON report mode and --format json is rejected. A reported deletion count is evidence of completed removals and does not imply rollback of an earlier removal.

    Exit status

    Exit 0 when every eligible removal completes, including when there are no eligible workspaces.

    Exit 1 for invalid arguments, failure to inspect managed storage or a failed eligible deletion. Earlier completed removals remain completed on a later failure.

    Filesystem effects

    Require a real child directory with a valid regular .topaz-workspace.json marker using topaz.storage.workspace.v1. Skip unowned paths, invalid markers, symlinked workspaces and symlinked markers.

    Remove a directory only after the owner is confirmed inactive. A live owner remains protected after 24 hours. Retain the directory when liveness is uncertain. Revalidate the marker and owner state immediately before deleting.

    Delete only the selected owned subtree and do not follow nested symlinks outside it. A concurrent disappearance is harmless. Do not change files in retained workspaces or delete caller source, package output or arbitrary directories.

    Network access

    Perform no network access. Local process inspection does not authorize contacting a remote host.

    Reproducibility

    Cleanup is state dependent and changes the input state. A second run after a successful cleanup reports zero additional removals unless another eligible workspace appears.

    With an identical managed storage snapshot and liveness observations, the same paths are eligible and processed in the same order. Creation time alone never makes a live owner eligible.

    Packages and locks

    Cleanup does not read or rewrite the current package manifest or lock and does not remove its vendored dependencies. Package locks and compiler workspace ownership markers are different records.

    Do not run dependency resolution or materialization to decide which workspaces are owned.

    이유

    Cleanup authority comes from a validated ownership marker and confirmed inactivity. A directory path or an old creation time is not proof that deletion is safe. Rechecking ownership and liveness at deletion time protects a running build from a stale inspection result.

    The linked public CLI recipe checks the exact displayed argument rejection before the requested operation. It does not execute the successful operation or verify its effects.

    The reviewed recipe supplies an extra operand and stops before cleanup. The old live owner retention scenario needs isolated managed storage and a controlled live process and is not an executable recipe under the current allowlist.

    Example

    링크

    Argument-rejection example

    링크
    main.tpzArgument-rejection example플레이그라운드 열기 →
    1. function identity<T>(value: T) -> T {
    2. value
    3. }
    대상 제품 5.21.3
    기대 결과

    기대 결과

    Textual rejection details remain Pending in the reference model. The independent Tools example gate expects exit 1.

    Reject the adapter-supplied extra positional operand before listing or removing any workspace. The current dispatcher falls back to an unknown-command error for the storage family.

    Verification scope

    링크

    Observed with Topaz 5.21.3 on 2026-11-06T08:36:29.642Z. This invocation passed; exit 1. 3 assertions were evaluated against the independent expected result. Execution record. This result covers the displayed invocation.

    Related references

    링크

    Compiler selection →

    Packages, locks and targets →

    메뉴

    다운로드 →