Celestial Software

I found another problem!
Once abort the session during recieving a file, zmtx will display the left content of the file on the screen.
Can you disable this funtion? Or use the resumable tranfered method?

Gee, you're a tough customer!

I don't want you to think that I'd forgotten about this. It just took me awhile to come up with the solution. First, zmtx does *not* react well to aborted transfers. It gets the first character of the abort sequence, but continues to send. However, AbsoluteTelnet was having problems even with lrzsz and rzsz with the file transfer data being displayed on the screen, so clearly something needed to be done.

The fix is to have Absolute wait awhile after the transfer is cancelled, flushing all of the data that may be buffered in the network, the ssh2 layer, or the zmodem layer. This way, nothing is accidentally sent to the screen. One side-affect is that you will also not get the prompt back because it is flushed along with the extra data.

You can try the new version here:

http://www.celestialsoftware.net/telnet/...teTelnet3.86RC22.exe

zmtx has an additional problem because it doesn't recognize the cancel command. It will continue to send data anyway. So, what happens is that if you cancel in the middle of a receive, AbsoluteTelnet will sit and wait for the sender to stop sending. zmtx will continue to send the entire file. AbsoluteTelnet discards all of the extra data, but still has to wait for it to stop, so it might wait for quite some time, depending on the file size and transfer speed.

I do have a fix for this, but I don't know where to send it. zmtx doesn't seem to be maintained any more, or at least I haven't found a maintainer or a website for it. The latest version is 1.02, and it hasn't been updated in a dozen years or so.

Another problem is in zmrx if you try to send a file that already exists. If the file was originally only partially transferred, zmrx can initiate a resume, and that works fine. However, if the file already exists and is complete, it will fail.

For example, say you were sending 10 files in a batch. If you start zmrx and select all 10 files, it will begin to send. Now, say your connection fails during the transfer of the fourth file... If you start zmrx again and specify all 10 files again, it will fail on the first one. What I would expect to happen is this...

a. Skip over the first three, because they're done.
b. Resume the fourth file where it left off
c. continue transferring files 5-10

I have a partial fix for this one, but maybe this one is not a big deal for you.

In any case, I'd still look into getting lrzsz working. None of these issues exist there. I'm not sure if you lrzsz problem is AbsoluteTelnet related or a problem with your install, but it at least is actively supported and maintained.

Brian

Hello, Brian!
Thanks for your hard work!

I tested 3.86RC22, and found it transfers files well while using drag/drop. But it doesn't work by selecting menu command.

I tested lrzsz again, but...

I installed two clean freebsd(minimal). 4.11 and 5.4. And only added lrzsz and zmtx-zmrx package. But it still made some errors. So, I don't think it come with system configure.

a. Skip over the first three, because they're done.
b. Resume the fourth file where it left off
c. continue transferring files 5-10looking forward to seeing if these funtions were available!

Do you want to release the freebsd version of lrzsz or commit patch of zmtx-zmrx to freebsd ports?

Another question:
How can I use Home and End key when terminal type is xterm?

Yi Wang

[ October 12, 2005, 11:22 AM: Message edited by: wangyi6854 ]

I tested 3.86RC22, and found it transfers files well while using drag/drop. But it doesn't work by selecting menu command.ZModem doesn't really work well with the menu options. It's designed to work with the auto-start feature of zmodem. In order to start a send or receive, the proper command has to be submitted on the host side. (zmtx, zmrx). XModem and YModem must both be started using the menu commands because there's no autostart feature. ZModem can be started from the menu if the autostart feature does not work, but the host-side program must be running first.

Do you have a system I could login to to test lrzsx in your environment? I don't have a problem here.

As for home ane end,

The HOME key sends CSI1~ and END sends CSI4~

The exact output depends on the value chosen in the option (Options->Properties->VT Options->Absolute sends 7/8 bit control sequences)

Normally, 7bit should be used in Unix systems, so Home will send:

ESC[1~

and END will send:

ESC[4~

In 8bit mode, the ESC[ is replaced with the 8-bit CSI character, which I believe is x9B

If your home/end keys are not working, it could be that the application you are using does not recognize them. You may try switching the 7/8 bit option and see if that makes a difference. 7bit is probably what you should use.

If you have further questions, let me know.

Brian

I'm using ADSL now, so I don't have a static ip.
You can test lrzsz in vmware. In my machine, it doesn't work too.(freebsd 5.4, 4.11. vmware 5.0)

HOME and END key does not work yet when terminal type is xterm, but work when selecting vt220.
cat -v shows it sends ESC[1~ and ESC[4~ both in xterm and vt220, but only in vt220, it can recognize them.
7 bit and 8 bit also tested.

Does different os produce different effect? Does these keys work properly in linux?

thx!

I only have VMWare 4. Can you point me to a freebsd image for vmware4?

If not, I could still log into your IP, even if it is not static. It would at least stay the same for awhile. Ever hear of Dynamic DNS?

Different OS can make a difference only because the defaults and mappings may be different. It mostly depends on the application. What app are you using that recognizes the home and end keys? vi? shell?

Brian