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

Aperta
  • Qualcosa non va?
#64 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Go
Stelle
3
Fork
4
Merge medio
3g 19h
PR unite (30g)
5

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di tidbcloud/ti-cli

Tutte le issue di tidbcloud/ti-cli

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.