Aleksa Sarai

Here's a simple reproducer -- note that in this case, `Read` is called until the end of the stream is reached and then `WriteTo` is called. https://play.golang.org/p/touWFY2ATjv ```go package main...

> @cyphar It this without limit? There must be a limit to how far it can read ahead, otherwise you will easily run the system out of memory. Yeah it's...

I'll take another look at how to fix the deadlock issue without switching to `sync.Pool`...

@klauspost The `io.EOF` handling is fixed in a separate commit ([`gunzip: handle io.EOF errors correctly in WriteTo`](https://github.com/klauspost/pgzip/pull/40/commits/cb18aaa4accad314857503f49375ba381a3387c9)), but the unit tests require the deadlocks to be fixed. @rubenv > Problem...

Turns out this also happens if you use `io.Copy` twice, though the stack trace is slightly different. https://play.golang.org/p/k-yT6L2pzj1 ```go package main import ( "fmt" "bytes" "io" "io/ioutil" "github.com/klauspost/pgzip" ) //...

`apt` fails because something odd is going on with how it's forking, I wasn't able to figure it out and haven't worked on this project much recently. I'm not sure...

Yes, I think I made a mistake here. I'll check the Linux cred code to see where I've messed up.

Unfortunately my current view is that we should entirely ditch `tar` and come up with a better format. I'm currently working on a blog post to describe what it would...

`continuity` doesn't have the deduplication that would be incredibly useful for massively reducing the network and storage overhead -- it has a somewhat similar model to `tar` except it separates...

I'm not sure about that -- packfile does store deltas of similar files (which is what that page says) but that is very different to content-defined chunking (you aren't storing...