Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Trying to copy a large file from a container via kubectl cp with the new flag results in the following error: I executed the following command: EDIT: The command executes and the file is copied. However, the resulting file is somehow corrupted: However, the files have exactly the same size locally and on the pod: Also, the command exits with non-zero code and thus scripts may stop or abort at this point. What you expected to happen: The large file to be downloaded from the container completely and unharmed. Exit code 0 only if copy was successful How to reproduce it (as minimally and precisely as possible): Add a large file (mine was ~150M) to any location in the pod (preferrably a tar file). Execute kubectl cp to download the large file and use the flag. Try to untar the resulting file Anything else we need to know?: Related to Issue . I only experience this issue if I see kubectl doing at least one retry. Environment: Kubernetes version (use kubectl version): server v1.20.12, client v1.23.1 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Kernel (e.g. uname -a): Install tools: Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
tar: Removing leading `/' from member names so cancel first "/" from "" like this: k cp --retries=-1
Thanks for the hint. The warning is a and I was just ignoring it in my case. This issue is about the error message and the command exiting with a non-zero exit code.
I just updated the issue description, we see the tar files being corrupted after kubectl did at least one retry
/assign atiratree
Is it correct to start at position bytesRead+1? Or should this be bytesRead instead? For example, if 1 byte was read (position 0), we would want to resume from position 1, not position 2. Just a thought, I haven't really looked at what initReadFrom does.
It should be correct since the byte start of tail (part of implementaion of initReadFrom) and bytes read match. Meaning that when we read 10 bytes we want to start reading 11th one. The actual problem was that we were running a wrong command when -1 retries is used: please see

Discussion:
Command:  []string{"tar", "cf", "-", t.src.File.String()}, Executor: &exec.DefaultRemoteExecutor{}, } <del> if t.o.MaxTries > 0 { </del> <ins> if t.o.MaxTries != 0 { </ins> options.Command = []string{"sh", "-c", fmt.Sprintf("tar cf - %s | tail -c+%d", t.src.File, n)} }

n, err = t.reader.Read(p) if err != nil { if t.o.MaxTries < 0 || t.retries < t.o.MaxTries { <ins> t.retries++ </ins> fmt.Printf("Resuming copy at %d bytes, retry %d/%dn", t.bytesRead, t.retries, t.o.MaxTries) t.initReadFrom(t.bytesRead + 1) err = nil <del> t.retries++ </del> } else { fmt.Printf("Dropping out copy after %d retriesn", t.retries) }