[Bug] copy-file --tag replaces a file's whole tag set, and --to-stdout ignores --layer-id

未关闭
  • 哪里不对？
#64 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
55/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
cli

调研方向

Start at the fs copy-file command entry point and trace how repeated --tag values are handled for an existing remote path, then compare --to-stdout with the existing --to-local layer-id validation. Add regression coverage for preserving or explicitly rejecting existing tags and for refusing or honoring --layer-id on stdout; done means neither request silently loses data or returns exit 0 with the wrong result.

由索引模型根据 Issue 内容生成。

描述

ti version

0.2.7 (6c950c77a601d0d55394c4b2f64483ae93d522db, 2026-09-27), bundled ti-drive9 companion 60b63d6

Command family

fs

Operating system and architecture

macOS 14.6, darwin/arm64, for the tag behaviour. Ubuntu, linux/amd64, for the layer behaviour.

Summary

Two copy-file behaviours lose data or return wrong data, and both exit 0 with no warning. A
caller has no signal that anything went wrong.

Covers observations 13 and 9 from a review of the TiDB Cloud Filesystem documentation.

Problem 1: --tag replaces the existing tags instead of adding to them

Command
ti fs copy-file --from-local ./a.txt --to-remote /a.txt --tag stage=review --tag owner=alice
ti fs copy-file --from-local ./a.txt --to-remote /a.txt --tag team=docs
Reproduction steps
  1. Create a file system and upload a file with two tags.
  2. Upload to the same remote path again, supplying one different tag.
  3. Inspect the tags with describe-file, and search for the original tag with find-files.
Expected behavior

Either the new tag is added to the existing set, or the command refuses and says that
supplying --tag on an existing path will discard the current tags.

Actual behavior

The original tags are discarded silently, at exit 0. Searches that relied on them stop
matching.

$ ti fs copy-file --from-local ./a.txt --to-remote /a.txt --tag stage=review --tag owner=alice
  exit=0
  tags: {'owner': 'alice', 'stage': 'review'}

$ ti fs copy-file --from-local ./a.txt --to-remote /a.txt --tag team=docs
  exit=0
  tags: {'team': 'docs'}

$ ti fs find-files --path / --tag stage=review --output text
  PATH  NAME  SIZE  SCORE

Related observations from the same testing:

  • Omitting --tag on the re-upload preserves the existing tags, so the loss happens only
    when --tag is supplied.
  • --tag "" is accepted at exit 0 and ignored, so there is no way to clear tags.
  • Re-uploading over an existing path succeeds without --overwrite.
  • Of all ti fs subcommands, only copy-file, create-layer, and find-files accept
    --tag. Nothing tags a file that already exists, so re-uploading is the only way to change
    a tag, which is exactly the path that discards the others.

Problem 2: --to-stdout ignores --layer-id and returns base content

Command
ti fs copy-file --from-remote /file.txt --to-stdout --layer-id "<layer-id>"
Reproduction steps
  1. Create a file whose base content and layer content differ.
  2. Read it with --to-stdout --layer-id <layer-id>.
  3. Compare with the same read using --to-local.
Expected behavior

Either the layer content is returned, or the command refuses, as it already does for
--to-local.

Actual behavior

The base content is printed at exit 0. The layer selection is silently discarded. The same
request with --to-local is refused, with --layer is only supported for uploads or remote-to-remote copy targets, so the rejection exists but does not cover the stdout path.

A caller reading a layer this way receives the wrong data and is told nothing.

Why these are grouped

Both are copy-file returning success while quietly doing something other than what was
asked. Problem 1 destroys metadata, problem 2 returns the wrong bytes. Either would be caught
immediately if the command refused instead.

Sensitive-data confirmation

No API keys, file system or Vault tokens, database credentials, connection strings, SQL, or
customer data appear above. File systems used for these measurements were deleted afterwards.

主要语言
Go
星标
3
派生
4
平均合并
3 天 19 小时
30 天内合并 PR
5

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

tidbcloud/ti-cli 的其他 Issue

查看 tidbcloud/ti-cli 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。