<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to bugs</title><link>https://sourceforge.net/p/dotnetssh/bugs/</link><description>Recent changes to bugs</description><atom:link href="https://sourceforge.net/p/dotnetssh/bugs/feed.rss" rel="self"/><language>en</language><lastBuildDate>Wed, 02 Jul 2014 07:56:54 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/dotnetssh/bugs/feed.rss" rel="self" type="application/rss+xml"/><item><title>#3 SCP - receive file</title><link>https://sourceforge.net/p/dotnetssh/bugs/3/?limit=25#d23c</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Mr. Zdukic,&lt;/p&gt;
&lt;p&gt;This turned out to be very helpful!&lt;/p&gt;
&lt;p&gt;Thank you for sharing.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;br /&gt;
&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Johan Heyvaert</dc:creator><pubDate>Wed, 02 Jul 2014 07:56:54 -0000</pubDate><guid>https://sourceforge.netb0dedd820b15e35c1b20d65140d5cfae20fc17eb</guid></item><item><title>SCP - receive file</title><link>https://sourceforge.net/p/dotnetssh/bugs/3/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;This problem occured when I was downloading 0.5MB file from embedded device. Every ~16kB there were missing 9 bytes. It seems that slower devices can not prepare full buffer, like the code was supposing. So, SCP_ReceiveFile method should be corrected like this:&lt;/p&gt;
&lt;p&gt;protected void SCP_ReceiveFile(Stream server, string rfile, string lfile, int size)&lt;br /&gt;
{&lt;br /&gt;
int copied = 0;&lt;br /&gt;
SendStartMessage(rfile, lfile, size, "Connected, starting transfer.");&lt;br /&gt;
// read a content of lfile&lt;br /&gt;
//FileStream fos = File.OpenWrite(lfile);&lt;br /&gt;
FileStream fos = File.Create(lfile);&lt;br /&gt;
int foo;&lt;br /&gt;
int filesize = size;&lt;br /&gt;
var buf = new byte[1024];&lt;br /&gt;
while (!_mCancelled)&lt;br /&gt;
{&lt;br /&gt;
if (buf.Length &amp;lt; filesize) foo = buf.Length;&lt;br /&gt;
else foo = filesize;&lt;br /&gt;
int len = server.Read(buf, 0, foo);&lt;br /&gt;
copied += len;&lt;br /&gt;
fos.Write(buf, 0, len); // it was: fos.Write(buf, 0, foo);&lt;br /&gt;
SendProgressMessage(rfile, lfile, copied, size, "Transferring...");&lt;br /&gt;
filesize -= len; // it was: filesize -= foo;&lt;br /&gt;
if (filesize == 0) break;&lt;br /&gt;
}&lt;br /&gt;
fos.Close();&lt;br /&gt;
if (_mCancelled)&lt;br /&gt;
return;&lt;br /&gt;
SCP_CheckAck(server);&lt;br /&gt;
SendEndMessage(rfile, lfile, copied, size, "Transfer completed successfuly (" + filesize + " bytes).");&lt;br /&gt;
}&lt;/p&gt;
&lt;p&gt;Notice that value foo is always 1024 (buffer length), but the actual received data is len and does not have to be 1024.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">zdukic</dc:creator><pubDate>Tue, 18 Dec 2012 16:44:09 -0000</pubDate><guid>https://sourceforge.netaf85289fcb6fd14d433a5f03dd9ccf615af0f933</guid></item><item><title>SshExec hangs on Mac OS X with lenghty execution</title><link>https://sourceforge.net/p/dotnetssh/bugs/2/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;The problem reproduces on Mac OS X 10.4, 10.5, 10.6 : PPC/i386 : Server/Workstation. The problem does not reproduce on AIX, HPUX, SOLARIS, Linux. The hang occurs if the remotely executed script takes 20 or so seconds to return. The hang does not occur with instantaneous output shell commands like "uname -s" for instance. It does not matter whether remote script produces the output or not for hang to occur. The script actually finishes OK and does not get interrupted by this hang. So, the issue is only that the output is not displayed and the session hangs indefinitely without disconnecting. This forces user to press CTRL-C in the console application to return back to the command prompt. The problem originally also reproduced when using SharpSSH-1.1.1.13, so this is likely a legacy problem from the original version prior to project's fork. When tested similar functionality with Plink tool (see Putty download page) the problem did not reproduce. However, Plink.exe utility has an option to enable PTY allocation (switch -t: enablePtyAllocation). This played an important role on whether the hang reproduced on various OS or not with Plink. Proposed fixes: Option 1: Implement timeout mechanism in SshExec, this is more of a patch approach. Not serious permanent solution. Option 2: Fix the actual problem with the session hang by implementing PTY allocation. &lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">unixrobot</dc:creator><pubDate>Mon, 21 Feb 2011 20:31:02 -0000</pubDate><guid>https://sourceforge.netbd9aa4999f156835c5aab0001afb4c5690cb5bfe</guid></item><item><title>Example user SFTP interface compares incorrect strings</title><link>https://sourceforge.net/p/dotnetssh/bugs/1/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;In SshFileTransferTest the user options read mixed case text, check against lowercase but then return the mixed case before deciding what to do against lower case.&lt;/p&gt;
&lt;p&gt;Suggest changing GetProtocol and GetTransferDirection to return the lowercase version:&lt;/p&gt;
&lt;p&gt;public static string GetTransferDirection()&lt;br /&gt;
{&lt;br /&gt;
string dir;&lt;br /&gt;
while (true)&lt;br /&gt;
{&lt;br /&gt;
Console.Write("Enter transfer direction [To|From]: ");&lt;br /&gt;
dir = Console.ReadLine().ToLower();&lt;br /&gt;
if (dir.Equals(string.Empty)) break;&lt;br /&gt;
if (dir.Equals("to") || dir.Equals("from"))&lt;br /&gt;
break;&lt;br /&gt;
Console.Write("Bad input, ");&lt;br /&gt;
}&lt;br /&gt;
return dir;&lt;br /&gt;
}&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Paul Atkin</dc:creator><pubDate>Wed, 11 Aug 2010 00:05:31 -0000</pubDate><guid>https://sourceforge.netb5cc0ea26f97b1435cf74b4e727fa9c38eb24e6b</guid></item></channel></rss>