ZMODEM support

[GoogleCodeExporter]

Hi,

please add Z-Modem support for file up and downloads.

There is an open source implementation of the Z-Model protocol available at 
http://www.ohse.de/uwe/software/lrzsz.html 

Although lrzsz is only at version 0.12.20, it is rock solid and i've been using 
it for years SecureCRT.

Ideally, when sending a file (upload), one should just drag and drop the file 
on the terminal. When receiving a file (download), a dialog should pop up and 
ask where to store that file. Also, there should be an configuration parameter 
to specify a default download location.

Thanks :)

Original issue reported on code.google.com by rojaro@gmail.com on 16 Nov 2010 at 2:11

[GoogleCodeExporter]

Konsole appears to be the only Linux terminal that implements this. I'll need 
to investigate how.

Drag and drop into the mintty window is already used to insert a file's path, 
which conflicts with that part of your request.

Original comment by andy.koppe on 16 Nov 2010 at 9:27

• Changed title: ZMODEM support
• Added labels: Difficulty-Hard, Priority-Low

[GoogleCodeExporter]

Original comment by andy.koppe on 16 Nov 2010 at 9:28

• Changed state: Accepted

[GoogleCodeExporter]

You could add a 'OnFileDrop' property to affect the behavior for the drop event 
:)

Original comment by rojaro@gmail.com on 16 Nov 2010 at 10:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Btw, as i already offered a 100Euro bounty for the same feature to be 
implemented in iTerm, i am also going to do the same for this here.

When this feature is present in MinTTY, i will send 100Euro to the author :)

Original comment by rojaro@gmail.com on 16 Nov 2010 at 10:12

[GoogleCodeExporter]

Thanks for the offer, but I'm afraid I'm unlikely to be able to find the time 
for this, so the bounty is there for someone else to claim.

A few thoughts on this:

- GNU screen has zmodem support. Build and install lrzsz and put 'zmodem catch' 
into ~/.screenrc. It detects when a zmodem transfer in either way has been 
started on the remote side and invokes rz/sz locally. Unfortunately I couldn't 
get it to actually transfer any files though, and it messed up the termios 
settings. If someone can get it to work though, I'd be happy to include a tip 
about it on the Tips wiki page.

- There are of course plenty of alternatives for transferring files between the 
local and remote system (scp, ftp, samba, nfs, ...), but having the ability to 
transfer files directly in the terminal would arguably be more convenient.

- Zmodem's synchronisation, error checking, and flow control features were 
crucial for error-prone modem connections, but are unnecessary for network 
connections where that's already handled lower in the stack.

- Zmodem's control sequences are rather bizarre and don't comply with the 
ECMA-48 standard on how terminal control sequences should be formed. In KDE's 
Konsole, inspite of its zmodem support, running sz on the remote end spills 
some of that control sequence garbage onto the screen.

- Konsole's 'ZModem Upload' menu item and the idea to trigger an upload by 
drag'n'drop are wrong in principle. They rely on being able to invoke rz at the 
remote end, which will fail miserably if the user is running something other 
than a shell, if no rzsz package is installed, or if the user happened to have 
already typed something on the current command line. It's not just that it 
won't transfer a file, but the initial sequence sent by sz contains a number of 
control characters, which might have all sorts of effects on the remote 
program. GNU screen has got this right in requiring an upload to be triggered 
at the remote end. In mintty, that should bring up a dialog for selecting which 
file(s) to upload.

- lrzsz appears to be licensed as "GPLv2 or later", which means its code could 
be used directly in mintty, but I suspect that would be a lot of work. A 
somewhat simpler alternative is to follow Konsole's example, which invokes rz 
and sz as separate processes. That still poses some significant challenges in 
plugging it into mintty's control sequence parser, select() loop and signal 
handling though, with plenty of scope for getting things wrong.

I'd much prefer a lightweight, ECMA-48 compliant protocol that could more 
easily be implemented directly in the terminal, instead of relying on external 
programs. This would probably be based on OSC sequences, similar to xterm's 
sequences for setting and getting the clipboard content. Unfortunately no such 
protocol appears to exist, and creating one would face the challenge of 
providing support for it on remote systems. Initially at least the client 
program(s) would need to be built and installed there manually.

So failing that, zmodem it is. As I said, I probably won't be implementing 
support for it myself, but I'd do what I can to integrate a patch, assuming it 
fits with my ideas of what it should do. Any GUI should use Win32 APIs, wheras 
plugging in lrzsz should be done with POSIX APIs. Obviously it would need to be 
well-tested and make some attempt at fitting in with mintty's existing coding 
style. I'd be very quick to throw it out if it turned out to break any existing 
functionality.

Original comment by andy.koppe on 3 Dec 2010 at 11:45

[GoogleCodeExporter]

Well, first, respect for your in-depth analysis :)

Anyway, i know that the Z-Modem protocol ain't the perfect solution and in 
absence of anything better, i think, better have Z-Modem than nothing.

About the control sequence garbage, about 20 years ago that wasn't any 
diffrent, of course we were using mostly DOS or Windows 3.x based terminal 
programms but they all displayed that garbage if i remember right :)

However, Z-Modem is old-school stuff and it expects that the user knows what he 
is doing, just like the 'rm' command expects that the user 'root' knows what 
will happen when he is executing it as 'rm -rf /*'. Also, there could be a 
simple dialog to confirm initiation of the filetransfer (well, maybe with an 
additional checkbox for seasoned users to disable the dialog).

Original comment by rojaro@gmail.com on 4 Dec 2010 at 12:35

[GoogleCodeExporter]

Could this be accomplished with tar/gz? Instead of typing "rz", you could type 
"tar xz", and then some user action in mintty (a mouse drop or a keystroke to 
bring up a file chooser) could initiate a tar/gz dump of the chosen files.

I guess control characters in the tar/gz data would be a problem, so maybe the 
tar/gz dump could be encoded with yenc, base64, uuencode, or something? You'd 
just have to type something like "yydecode | tar xz" on the remote end before 
starting the transfer...

Or would those encoders not work for a terminal session? Is that what you were 
talking about when you said there are no ECMA-48 compliant protocols?

Original comment by gom...@gmail.com on 25 Jul 2011 at 7:23

[GoogleCodeExporter]

After taking a quick look at yEnc, it does seem unsuitable, but maybe some 
other encoder would work...

Original comment by gom...@gmail.com on 25 Jul 2011 at 7:47

[GoogleCodeExporter]

FWIW, I just tried this with base64, and it worked:

$ base64 -d | tar xz
(paste base64-encoded .tar.gz file)
^D

This alone might be a workable solution for some cases, if there were an easy 
way to create a base64-encoded .tar.gz file in Windows.

Original comment by gom...@gmail.com on 25 Jul 2011 at 9:05

[GoogleCodeExporter]

Good news, everyone! I have developed a quick and dirty patch for mintty to 
support file transfers from remote servers. I'm generally happy with it now, 
but if Andy will decide to include this patch to the code base, I may continue 
to work on uploads and over enhancements.

Original comment by Serge.Sitnikov@gmail.com on 14 Apr 2012 at 12:29

Attachments:

• transfer.patch

[GoogleCodeExporter]

See https://github.com/mintty/mintty/issues for further progress on this issue.

Original comment by towom...@googlemail.com on 7 Aug 2015 at 1:26