SFTP uploads with less/higher than 32kb buffer size would corrupt

[TNTUP]

Hi, I'm using ShareX software developed by @Jaex and my issue related to it is here: ShareX/ShareX#1797

Jaex is using the SSH.NET library in his software so it allows me uploading images using SFTP then giving me a link to view it publicly. But since 11.2.1 the library got updated and causes images to distort (idk the correct term for this issue) corrupt on upload. See here as an example: http://i.qcfb.ca/20160819033042.png. Also (Thanks @Kiwi-1995 for those as an example haha)

https://chie.club/files/images/st/1819b4c5-4de7-4c93-90d9-e278a57bc8cc.png - Uploaded
https://chie.club/files/images/st/1819b4c5-4de7-4c93-90d9-e278a57bc8c2c.png - The original

(Credit to @Kiwi-1995 - His/Her issue here ShareX/ShareX#1802)

Setting the buffer size higher than 32kb causes this image corruption while using SFTP uploads. I tried lower 32kb, still occurs. Only 32kb fixed our issues (Workaround I've found)

[Nathanael-Mtd]

I need to add the corrupt problem appears since the 2016.0.0-beta1 of SSH.NET.

[drieseng]

I was able to reproduce this issue.
I'll probably fix it this weekend, and try to get a bugfix release out by next weekend.

[TNTUP]

Nice! Take your time 🎉

[drieseng]

Can you build SSH.NET from source and confirm that this effectively fixes the problem?

[TNTUP]

I don't have any VS 12/15 installed 😢

[Nathanael-Mtd]

I'm going to test in one hour.

[Nathanael-Mtd]

Nice job @drieseng, it works great now !
Thank you for your help.

[TNTUP]

@Nathanael-Mtd Mind sending me the .dll? I guess @Jaex can clone this repo (or he did already?) and update ShareX xD I can wait for the official release^^

[Nathanael-Mtd]

ShareX use nuget system, then it's useless. They are going to update their repo when SSH.NET devs are going to publish update to nuget.
(BTW, don't post on the other issue thread please, ShareX dev see what we write here.)

[TNTUP]

I'm not aware that still notify himself because I don't see him in the participants list ._.

[Nathanael-Mtd]

@TNTUP Because he's not participant. He's just a watcher. Now stop talking about that.
I think this Issue can be closed.

[ssolomon]

I have seen the same problem. And using 32k did not work either, just the problem was less pronounced. It seems that the write of the stream is reusing the first buffer, on the second call of a stream.write. I have tried the beta package, and it appears to fix the problem