FTP editing and crash losing edited documents

[dbuckley]

FTP editing rocks, especially via SSH.

However..... the other daythe network which connected the server which I was editing on had a "BGP fart" (yep, thats what they said happened, I kid you not) which caused the server to become unreachable for a while.

This was all unbeknownst to me, I was happily working at the time using Zeus, and asked it to save the file, as you do, and Zeus popped up a dialog box reporting something like that the remote server had returned a RST, and then when I OK'd the dialog box Zeus immediately closed.

Thus I get no chance to save the file elsewhere, and as it was partway through a file transaction on the server, the file on the server is zero length.

So, a days inspired editing lost. Consider me sulking.

The editor should have just behaved the way it does when it can't write the file, which is to report the fact and leave you with the file intact in the editor.

[jussij]

Can you tell me which version you are running (as displayed in the About box)

The editor should have just behaved the way it does when it can't write the file, which is to report the fact and leave you with the file intact in the editor.

Generally all Zeus actions are wrapped in a try/catch block. So when something catastrophic happens, Zeus will prompt with the crash dialog and will not actually die, thus giving the user a chance to recover any unsaved files

But in this case I suspect the error happened deep inside the ssleay32.dll that Zeus uses to do the SSH editing (NOTE: This is just the stock standard ssleay32.dll that can be found on the web).

Now because the error didn't actually happen in Zeus (it happened deep inside the dll) Windows never invoked the Zeus try/catch block meaning Zeus never got a chance to catch an process the error.

I suspect the DLL may not have even crashed. What probably happened is it detected the error and then just just called one of the C runtime abort, exit or assert functions, which then killed the current process. This would explain why Zeus just disappeared without a trace.

Cheers Jussi

[Guest]

Can you tell me which version you are running (as displayed in the About box)

Yes, sorry, 3.95s

[jussij]

Yes, sorry, 3.95s

That is very old version of Zeus that you are running

I would at least suggest backing up your current install and moving to the 3.95z found here:

http://www.zeusedit.com/forum/viewtopic.php?t=1000

The 3.95z release is 7 versions newer than your current version and is still a free upgrade

Cheers Jussi

[dbuckley]

Re the upgrade suggestion:

Thanks Jussi; I've taken that advice.

But back to the original question: is it possible to trap the ssl dll errors, or is that just impossible because of the way the errors are rasied and processed?

[dbuckley]

Problem with the upgrade - got an error message about inability to agree ciphers. Search of forum lead to this post, but the file it linked to isn't there. So I rescued the xnet.dll from the backup, and used that, and I'm back to a working editor

[jussij]

But back to the original question: is it possible to trap the ssl dll errors, or is that just impossible because of the way the errors are raised and processed?

In the current form, I think it is impossible to trap this error as there is nothing to trap

I suspect the error was detect by the ssleay32.dll (or by the libeay32.dll) and rather than reporting an error the dll just asked the operating system to kill the process.

The way it works is the xnet.dll is the Zeus wrapper dll that calls these other dlls.

I think the only way to fix this would be to get the code for ssleay32.dll and libeay32.dll and try to find where in the code the process is getting killed and change the code to try and return an error.

But I am a bit reluctant to do this since the code in these dll's was never written by me. The code belongs to OpenSSL.

The versions of these dll's that ship with Zeus are quite old so one thing you could try is using the newer versions of these dlls found here:

http://www.openssl.org/

With some luck they may have already fixed this issue in their latest dll

Also once I have some spare time I try to replicate the issue to see if the above theory is correct.

Cheers Jussi