You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is happening on the reading, not writing side (which you can verify by dumping the generated tar archive to stdout). According this section of archive/tar it looks like this is intentional:
default:
// According to PAX specification, a value is stored only if it is// non-empty. Otherwise, the key is deleted.iflen(value) >0 {
extHdrs[key] =value
} else {
delete(extHdrs, key)
}
}
Which begs the question, should we be generating xattrs that aren't valid according to PAX or should we accept such headers? I don't really mind either way, but it seems quite odd that we are liberal in what we generate but strict in what we accept.
The text was updated successfully, but these errors were encountered:
If the field is zero length, it shall delete any header
block field, previously entered extended header value, or
global extended header value of the same name.
Which means that zero-length values have a very specific meaning: deletion. So the correct solution is to prevent the tar.Writer from generating these bogus entries.
A lot of work happened on the tar.Reader in the Go1.8 cycle, and I was planning on vastly improving the writer in Go1.9, but really dropped the ball this cycle. Will attempt to get the fix in Go1.10.
dsnet
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Jun 16, 2017
dsnet
changed the title
archive/tar: empty-value Xattrs are dropped with Reader
archive/tar: Writer should not accept empty Xattr values
Jun 16, 2017
dsnet
changed the title
archive/tar: Writer should not accept empty Xattr values
archive/tar: Writer should not accept empty Xattrs values
Jun 16, 2017
You can verify this at https://play.golang.org/p/T9jR4DO492. Here's the contents of the paste:
What did you expect to see?
No output.
What did you see instead?
This is happening on the reading, not writing side (which you can verify by dumping the generated
tar
archive to stdout). According this section ofarchive/tar
it looks like this is intentional:Which begs the question, should we be generating
xattrs
that aren't valid according to PAX or should we accept such headers? I don't really mind either way, but it seems quite odd that we are liberal in what we generate but strict in what we accept.The text was updated successfully, but these errors were encountered: