This is a setup problem in your account on your server, not a PSCP/PSFTP bug. Your login scripts should never generate output during non-interactive sessions; secure file transfer is not the only form of remote access that will break if they do. On Unix, a simple fix is to ensure that all the parts of your login script that might generate output are in .profile (if you use a Bourne shell derivative) or .login (if you use a C shell). Putting them in more general files such as .bashrc or .cshrc is liable to lead to problems.
A.7.7 PSFTP transfers files much slower than PSCP. The throughput of PSFTP 0.54 should be much better than 0.53b and prior; we've added code to the SFTP backend to queue several blocks of data rather than waiting for an acknowledgement for each. (The SCP backend did not suffer from this performance issue because SCP is a much simpler protocol.)
A.7.8 When I run full-colour applications, I see areas of black space where colour ought to be, or vice versa. You almost certainly need to change the ‘Use background colour to erase screen’ setting in the Terminal panel. If there is too much black space (the commoner situation), you should enable it, while if there is too much colour, you should disable it. (See section
4.3.5
.) In old versions of PuTTY, this was disabled by default, and would not take effect until you reset the terminal (see question A.7.9
). Since 0.54, it is enabled by default, and changes take effect immediately. A.7.9 When I change some terminal settings, nothing happens. Some of the terminal options (notably Auto Wrap and background-colour screen erase) actually represent the default setting, rather than the currently active setting. The server can send sequences that modify these options in mid-session, but when the terminal is reset (by server action, or by you choosing ‘Reset Terminal’ from the System menu) the defaults are restored. In versions 0.53b and prior, if you change one of these options in the middle of a session, you will find that the change does not immediately take effect. It will only take effect once you reset the terminal.
In version 0.54, the behaviour has changed - changes to these settings take effect immediately.
A.7.10 My PuTTY sessions unexpectedly close after they are idle for a while. Some types of firewall, and almost any router doing Network Address Translation (NAT, also known as IP masquerading), will forget about a connection through them if the connection does nothing for too long. This will cause the connection to be rudely cut off when contact is resumed. You can try to combat this by telling PuTTY to send keepalives: packets of data which have no effect on the actual session, but which reassure the router or firewall that the network connection is still active and worth remembering about.
Keepalives don't solve everything, unfortunately; although they cause greater robustness against this sort of router, they can also cause a loss of robustness against network dropouts. See section 4.13.1
in the documentation for more discussion of this. A.7.11 PuTTY's network connections time out too quickly when network connectivity is temporarily lost. This is a Windows problem, not a PuTTY problem. The timeout value can't be set on per application or per session basis. To increase the TCP timeout globally, you need to tinker with the Registry.
On Windows 95, 98 or ME, the registry key you need to create or change is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
MSTCP\MaxDataRetries
(it must be of type DWORD in Win95, or String in Win98/ME). (See MS Knowledge Base article 158474
for more information.)