Category: PuTTY

After completing my recent “incident article” on emacs/tramp/win/putty [link], I thought I should prepare an article with a clear subject resp. statement. This is it.

I sort of think resp. hope, that all currently released versions work together well. But PuTTY-0.63 breaks this expectation.

• “Windows 7 Professional” is set – because that’s the current company standard
• http://www.gnu.org/software/emacs/windows/ – the latest released version was fine for me: 24.3.1 – I am always happy to get and try the very latest released version
• tramp – as packaged with the emacs at the location just referred to
• PuTTY to be found at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
• PuTTY-0.63 faults (for me) with accesses like this one: “/pscp:SESSIONNAME:…”
• PuTTY’s development snapshot does not fault for me, as 0.63 does – r10156 is, what I picked up – I am happy to try newer ones, if asked to, and I would rather prefer a released version to be honest

A released version is always easier to get installed officially, should I get the necessary privileges withdrawn to “install” resp. unpack packages myself. My privileges are good enough to put files “permanently” on the local disk, but not to “install” applications Windows-wise.

• http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html : 0.63 (released 2013-08-06) :

Unix: PSCP and PSFTP now preserve the Unix file permissions, on copies in both directions.

For quite a while whenever I edited a remote executable file (using emacs/tramp/putty on Windows), the file lost its executable privilige bit. Looks like that issue got solved with 0.63. What a relief! The very arrogant meritocrat at work kept criticizing me for using “such poor software“, and he referred to emacs(/tramp).

Short story – what (released) versions to choose:

The combination emacs/tramp/putty on Windows does not work with the released PuTTY-0.63. Use either PuTTY-0.62 or a PuTTY development snapshot, r10016 works for me.

• http://www.gnu.org/software/emacs/windows/ – the latest released version was fine for me: 24.3.1 – I am always happy to get the very latest released version
• tramp – as packaged with the emacs at the location just referred to
• PuTTY to be found at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
• PuTTY-0.63 faults with accesses as shown below
• PuTTY’s development snapshot does not fault for me, as 0.63 does – r10156 is, what I picked up – I am happy to try newer ones, if asked to
• Windows 7 Professional – because that’s the current company standard

Long story:

After the Windows upgrade at work (WinXP->Win7) I certainly installed the newest available emacs (i.e. emacs package) and PuTTY (0.63) as well.

Current issue: On opening a file accessed through “/pscp:SESSIONNAME:”, I keep getting this message:

Fatal: Received unexpected end-of-file from server

I tried the “/plink:SESSIONNAME:” tramp access instead, and it worked (I mean: it didn’t yield this message), but the combination tramp/plink keeps leading to corrupted (remote) files, as I described before [link], so that’s not really an option.

S.K.R. de Jong wrote [link], that the quoted message stems from an improper reaction of PuTTY, and Simon Tatham conceded the bug [link], writing the bug would be fixed with r10016.

Because I  found Simon’s statement and announcement only during my later investigations, I decided to give the older PuTTY-0.62 a try, and this problem actually disappeared. Of course I love leading / bleeding edge, but right now this seems to stand in my way. So I will have to post the scenario on some PuTTY forum / mailing list, but until that will lead to an improvement here, I shall stick to PuTTY-0.62.

When I had found Simon Tatham statement on this issue [link], I drew new hope, that a more modern version of PuTTY addressing the latest security issues  would also solve my problem – so I am giving the current development snapshot (to be found here) a chance, i.e. “r10156”. Actually I have never been eager to employ a development snapshot of PuTTY, so that is my “first“. I subscribed for the PuTTY-announce mailing list, so I shall be able to replace the development snapshot by a properly released one.

If that will not successful:

• TBD: first I shall have to find out, how exactly plink.exe gets called, so that the error message above gets causes – maybe I will have to ask the tramp support folks for help
• TBD: http://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html#feedback-bugs

The PC at “my” desk at my customer’s site just got migrated from WinXP to win7, and I have to re-install and re-configure a couple of packages, and now I have trouble re-adopting tramp.

Having to deal with tramp always brings Michael Albinus to my mind. I only met him during one week in 1988 (1989?), when I had only lived for a couple of months in Berlin. It was quite an enthusiastic time then, and we were so much younger then. Would he let me invite him on a couple of glasses of rather drinkable red wine in the future back home in Berlin?

Alright, back to the issue itself! Yes, after the Windows upgrade I certainly installed the newest available emacs (i.e. emacs package) and PuTTY (0.63) as well.

• http://stackoverflow.com/a/18764972/3119172 — I followed this advise on stackoverflow (please read and follow!!!) — I just summarize the steps briefly):

• byte-compile …/emacs/lisp/net/tramp-sh.el
• exit emacs
• remove ~/.emacs.d/tramp, i.e. the “tramp connection history” resp. the “tramp connection details cache“
• start emacs

and it seemed to find a proper “ls” command again.

I.e. I didn’t follow the other advise, demanding the installation of the newest tramp package.

Having solved the “ls” issue, I faced these messages:

Unable to use key file "…id_rsa.ppk" (unable to open file)
Fatal: Received unexpected end-of-file from server

The windows registry had a couple of entries named “PublicKeyFile” pointing to an outdated location, where id_rsa.ppk had resided before. Changed all occurrences of that entry within the registry (subtree of PuTTY), and that issue was solved.

I had a look here and look there for hours, … – accidentally I looked into the *Messages* buffer and found, that some file access within c:windowstemp failed. The system variables TEMP and TMP are initialized with c:windowstemp, but I have no rights to look into c:windowstemp. Alright, system variables can get overridden. And they actually were overridden. I just changed that to something very, very simple: c:temp. I restarted emacs, and everything was alright again.

PLINK.EXE is part of the PuTTY family, and it’s the utility tramp is communicating through.

“Burying” the respective tramp buffer in emacs is another one.

Update 2016-02-09:

Actually burying the tramp buffer in question is my 1st approach on all platforms (Linux/Mac/Windows), whenever tramp communication seems to be stuck. Afterwards (with a “clean new start”) everything is fine again in like 99% of the respective the cases.

• http://www.gnu.org/software/emacs/manual/html_node/emacs/Customizing-VC.html

I am working for a customer

• on WinXP
• with GNU Emacs 24.2.1
• through Tramp
• resp. putty plink (“pscp”)
• on AIX files.

They are using CVS on AIX, but as I am actually the only Emacs user there, I don’t really bother going through the set-up for using Emacs with CVS on WinXP.

Recently I looked into *tramp/pscp HOSTNAME*, and I decided I would be able cutting down on my waiting time, if I drastically reduced the list of files and directories being checked through VC in that environment.

I really don’t mind the VC overhead on OS X or (SUSE) Linux, but in that difficult environment I rather want to proceed as described.

I found vc-handled-backends and customised it the Emacs way, and I was done.