BC3 Becomes Unresponsive When SFTP Not Available

[SSnow]

I'm not certain whether this is a problem with ftp per se, or with the Linux version of BC3, but thought I would start by posting here.

I'm using version 3.07 under Ubuntu 8.04.1 along with openssh-server and sshfs so that I can synchronize the data on my two notebooks.

I also synchronize my primary data location with targets on two accessory drives on the main system.

When the secondary Ubuntu system is not on the network (or when I'm away from the network) I occasionally back up to the two accessory drives. If I accidentally click on one of the sftp sessions (the target being unavailable at this time) BC3 just wanders off into oblivion. Hitting the stop button on the toolbar does nothing. I have to kill the bcompare processes from the system monitor.

If I accidentally select a session which specifies one of the accesory target drives when they are not online, there is no problem. BC3 just tells me that the target is unavailable.

Is there a setting I can change that will prevent BC3 from behaving so badly when the sftp target isn't available?

[SSnow]

Okay, I'm goingto talk to myself just a little more. I spoke too soon. In version 3.09 I have the problem again. If I compare local to a remote target via sftp, and if the other system is unreachable due to a firewall issue on the remote system (and, perhaps for other reasons?) then Beyond Compare just continues to spin its wheels endlessly. It never errors out, and the Stop button on the toolbar or attempting to switch to another session has no effect whatsoever. The only way out is to open the system monitor (This is Linux I'm talking about.) and kill the bcompare processes.

I'd like to see the session fail much more gracefully, if possible. I don't know whether or not this affects the Windows version of the product.

BTW, every chance I get I want to tell you folks how much I love this software. I don't remember any other software that was ever quite so useful and excellent for so long. And I've been doing this since Apple I (yes, I) and CP/M on Zilog processors.

[Zoë]

I'm confused. Are you using BC's built in sftp:// support or sshfs?

[SSnow]

I'm confused. Are you using BC's built in sftp:// support or sshfs?

I feel fairly certain that you are NOT the person who is confused here.



When I first switched to Linux a few weeks ago I posted here to get a little help with installing and using BC3 to help me synchronize portions of my /home locations on two computers. At that time I believe one of my fellow end users helped me out with advice to install openssh-server and sshfs on the system. I may have misunderstood, but I gathered that these would make use of the sftp functionality in BC3 possible between the two systems.

At any rate, on each of these systems I allow a connection via SSH/port 22 from the other system through iptables. In BC3 I set up ftp profiles in each system for the other system. It works fine. But, if I try to connect to a copy of my data at a remote location and the admin there hasn't allowed the connection at the firewall, BC3 just sits there with the busy cursor. It will never come out of this state. (Well, I think it won't. I've waited as long as thirty minutes.)

I can duplicate this behavior locally on my own network by simply closing port 22 on the target machine. The initiating machine's instance of BC3 will behave exactly as in the above example of the remote network connection.

In these cases, hitting the stop button on the toolbar, or changing the session selection does nothing to bring BC3 out of the doldrums. I have to use the Linux system monitor to kill bcompare.

Thanks very much for your time and patience.

And, BTW, I enjoyed your interview -- the one Tim posted about.

[Zoë]

Ah, ok. sshfs allows you to mount the server as a directory, so BC will just treat it as part of the filesystem. You don't need that if you use BC's built-in SFTP support, but it would be a good way to work around the issue you're seeing now. Another alternative would be to just move your SFTP sessions into a subfolder so you're less likely to accidentally load them.

I don't have an Ubuntu 8.10 install handy right now, but I think Chris does. I'll have him look into it when he's back in the office. Assuming it's repeatable we'll try to get it fixed, but it may take a while before I have time.

[chrroe]

Hi,

I can reproduce the described endless-waiting described in the postings from SSnow. Here is my environment:

Windows XP SP2 as host PC
VMware Server 1.06
openSUSE 11.0 in a virtual machine
Beyond Compare 3.0.9 running with KDE4

- Now run msftpsrvr.exe from this site http://www.coreftp.com/server/index.html under Windows.
- Try to connect from the Linux VM to your windows system with BC3 via SFTP ==> fine
- Stop the SFTP server programm
- Full Refresh the directory in BC3 ==> endless waiting

Testing the other direction:
The Windows version of BC3 stops trying to connect after a few seconds if the SFTP connection is not available on Linux side.

Bye
Christoph

EDIT:
The connection timed out after 3'10 minutes.

[Zoë]

Thanks Christoph. I'll update the bug report.

[SSnow]

Ah, ok. sshfs allows you to mount the server as a directory, so BC will just treat it as part of the filesystem. You don't need that if you use BC's built-in SFTP support, but it would be a good way to work around the issue you're seeing now. Another alternative would be to just move your SFTP sessions into a subfolder so you're less likely to accidentally load them.

I don't have an Ubuntu 8.10 install handy right now, but I think Chris does. I'll have him look into it when he's back in the office. Assuming it's repeatable we'll try to get it fixed, but it may take a while before I have time.

Doh! Now I finally get it. Yes, I can try mapping the remote server as part of my file system, and then see if that fixes the issue. I have been using the built-in sftp support, for which which openssh-server was providing the target.

I'm trying to do too many things at once, and I'm not particularly good at doing one-thing-at-a-time.



Thanks.

[SSnow]

I can reproduce the described endless-waiting described in the postings from SSnow.

Thank you. I didn't want anyone (other than those who actually know me) to think I was imagining things.