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

Đang mở
  • Có gì không ổn?
#64 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
3
Fork
4
Merge trung bình
3 ngày 19 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tidbcloud/ti-cli

Tất cả issue của tidbcloud/ti-cli

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.