Consider adding a line about this new command in programs/zstd.1.md.

I think the only explicit use case is about compressing a file which is being appended to at the same time, thus changing its size during the compression process.

Setting the size to UNKNOWN disable any parameter adaptation, and make the behavior similar to what providing the input through a pipe would have done.

In contrast, just disabling the content size field, using ZSTD_CCtx_setParameter(cctx, ZSTD_c_contentSizeFlag, 0); would have given a chance to adjust the compression parameters to the first detected size of the file. This could make a small difference for smaller files.

My own preference would be for the second case, though I have no "strong" reason for that, just some "gut feeling", essentially because it feels closer to the expressed command : "no-content-size", rather than "no-content-size-and-assume-large-file". But anyway, I suspect the difference between these 2 options is pretty small and won't matter much.

I'm in favor of keeping parameter adjustment as well.

Ah okay then! Haden't thought about changing parameters honestly but that makes sense to me. I'll change it to unset ZSTD_c_contentSizeFlag instead of setting filesize to unknown.

I thought I noticed Travis failing but it's okay now. Guess it was flakey:/

I thought I noticed Travis failing but it's okay now. Guess it was flakey:/

Yeah, I re-ran it and it passed. Seemed to be some infra flakiness, because it was a super weird issue.