304 Missing Bytes After Encrypt and Decrypt Large files #312
Conversation
In a previous version the code called lData.Close() but that is marked as obsolete.
The Obsolete attribute says it all.
[Obsolete("Dispose any opened Stream directly")]
813442d to
78dfccb
Compare
|
Thanks for this. Looks good to me but seems that the workflows have started failing, probably some of the actions are out-of-date. I'll take a look at them this evening and then try and put a new release. |
|
FYI - take it or leave it, I just wanted to share what I observed Armoring BufferSize of 4096 |
|
Thanks for looking into the performance. That's a good catch on the PipeStreamContentsAsync, I can't remember why I was using this rather than Stream.CopyTo but I'll create another PR to switch over to using Stream.CopyTo given the performance improvements. I hadn't realised that armouring had such a big impact. I think it's probably too disruptive to change the default at the moment though I'll update the readme with your findings so people are aware that they can increase performance if they don't use it. |
In a previous version the code called lData.Close() but that is marked as obsolete. The Obsolete attribute says it all.
[Obsolete("Dispose any opened Stream directly")]
https://github.com/bcgit/bc-csharp/blob/5095a56b7d23ec370e58d45c6445d17ca85f94f6/crypto/src/bcpg/BcpgOutputStream.cs#L66
If you look here you can see how once a stream length exceeds 4gigs (0xFFFFFFFFL) it starts using a different approach that includes the partialBuffer.
The Close() used to call the PartialFlush() which would write out the contents of the partialBuffer.
With that gone, there is still some bytes in the partialBuffer.
Finish() calls PartialFlush.
Finish is called in the Dispose method