`docker context export` writes a truncated tar archive
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 92/100
Rechercherichtung
Beginne mit Export() in cli/context/store/store.go und prüfe, wie der tar writer und der output writer geschlossen werden. Führe die vorhandenen Tests in cli/context/store aus und überprüfe anschließend, dass ein exportierter Kontext mit TLS-Dateien ein vollständiges tar-Archiv ist, das von Python tarfile und macOS tar akzeptiert wird.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Description
docker context export writes a truncated tar file. The two zero blocks that end a tar archive are never written, and when the context has TLS files, the padding after the last file is missing too.
docker context import still reads these files, because Go's archive/tar stops quietly at EOF. Other readers are stricter: with TLS files in the context, Python's tarfile rejects the export, and so does the macOS tar when reading it from a pipe (output below).
The cause is the order of these deferred calls in Export() in cli/context/store/store.go:
tw := tar.NewWriter(writer)
defer tw.Close()
defer writer.Close()
Deferred calls run last-in, first-out. So the pipe is closed first, and when tw.Close() then tries to write the padding and the trailer, it gets io.ErrClosedPipe. That error is ignored. The code hasn't changed since the context store was added in b34f340346f (2018).
Reproduce
$ openssl req -x509 -newkey rsa:2048 -nodes -keyout /dev/null -out ca.pem -days 1 -subj "/CN=example"
$ docker context create example --docker "host=tcp://127.0.0.1:2376,ca=$PWD/ca.pem"
example
Successfully created context "example"
$ docker context export example example.tar
Written file "example.tar"
$ wc -c < example.tar
3667
A tar file is always a multiple of 512 bytes, and 3667 isn't (the exact size depends on the certificate). The file stops 83 bytes into a block, right after the contents of tls/docker/ca.pem:
$ python3 -m tarfile -l example.tar
Traceback (most recent call last):
...
ReadError: unexpected end of data
$ docker context export example - | tar -tf - > /dev/null
tar: Truncated input file (needed 1536 bytes, only 1107 available)
tar: Error exit delayed from previous errors.
Expected behavior
A complete tar file: each file padded to a 512-byte boundary, then the end-of-archive marker. Other tar tools should be able to read the export too.
docker version
Client:
Version: 29.8.0
API version: 1.56
Go version: go1.26.8
Git commit: 88096ef
Built: Thu Sep 3 21:49:43 2026
OS/Arch: darwin/amd64
Context: default
Server: Docker Desktop 4.91.0 (239619)
Engine:
Version: 29.8.0
API version: 1.56 (minimum version 1.40)
Go version: go1.26.8
Git commit: 3ce5872
Built: Thu Sep 3 21:51:20 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.3.4
GitCommit: db8809540e1a7a9da5d518876894933ff55692ab
runc:
Version: 1.4.3
GitCommit: v1.4.3-0-gbb14dabe
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
N/A, the daemon isn't involved. This happens in the CLI's context store (cli/context/store).
Additional Info
Same result with the CLI built from master (7fc2dff9bc).
Without TLS files the archive happens to end on a block boundary, and the readers above accept it. The end-of-archive marker is still missing, though.
Closing the tar writer before the pipe fixes it. With this change, the export from the steps above is a complete archive that both readers accept, and the existing tests in cli/context/store still pass:
tw := tar.NewWriter(writer)
defer func() {
// Close the tar writer first, so that the padding and the
// end-of-archive marker are written before the pipe is closed.
writer.CloseWithError(tw.Close())
}()
Happy to open a PR for this.
- Vorherrschende Sprache
- Go
- Sterne
- 6.1k
- Forks
- 2.2k
- Ø Merge
- 1 T. 11 Std.
- Gemergte PRs (30 T.)
- 45
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus docker/cli
-
kind/bug status/0-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 1 Tag
-
kind/bug status/0-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
docker/cli#7176 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
docker/cli#7005 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
kind/feature status/0-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
docker/cli#6919 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
kind/bug status/0-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
docker/cli#6917 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Ähnliche Issues
-
bug needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
netdata/netdata#24062 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
meshery/meshery#22119 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
automation documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag