private_meta wrote:

- Check when connecting if a second session is possible. if not, disable background transfer

That's basically what is being done, isn't it?

- Change Background Transfer/Queue to Foreground transfer if a second session is not possible (maybe with user interaction yes/no/cancel)

Well, and what if you start foreground transfer meanwhile?

martin wrote:

OK, I understand the problem. But what do you suggest WinSCP should do instead?

As you said previously that it depends on the WinSCP-Designs I don't know what could work there. It might be that this problem faces the same difficulties as the session problem.

I can think of some possibilities:
- Disable browsing session (yet, same problem as before i think)
- Possibility to disconnect so the background transfers can be done (not that much of a good idea i guess)
- Check when connecting if a second session is possible. if not, disable background transfer
- Change Background Transfer/Queue to Foreground transfer if a second session is not possible (maybe with user interaction yes/no/cancel)

I don't know if any of those options are eligible for you, I hope one of them is.

OK, I understand the problem. But what do you suggest WinSCP should do instead?

martin wrote:

private_meta wrote:

Apart from that I had the second issue about failing background download if a second connection is not allowed. Can something be done there (out of curiosity), as it might be a different kind of code to be changed there.

What issue do you mean?

Sorry If I didn't clarify that earlier.

If you only have one session (that's why it also fits into this thread) and you queue something, all it does is

1. try to connect
2. fail
3. remove item from queue
4. go to 1. if queue isn't empty

So basically you end up with an empty queue and a load of error messages. Of course you can just go around that by not using the queue, it just thought it'd be weird.[/list]

private_meta wrote:

Apart from that I had the second issue about failing background download if a second connection is not allowed. Can something be done there (out of curiosity), as it might be a different kind of code to be changed there.

What issue do you mean?

martin wrote:

That's true. Actually if I was to design WinSCP today, I would do it this way. But unfortunately WinSCP is not designed to operate this way :-(
And redesign would be too costly to justify the little gain of possibility to browse local size, changing preferences, and similar tasks.

Ah, too bad. I didn't think it would be that much difference. I thought it would just amount to always transferring it in background and just give the transfer session priority over the browsing session (in case only one session is allowed)

Apart from that I had the second issue about failing background download if a second connection is not allowed. Can something be done there (out of curiosity), as it might be a different kind of code to be changed there.

cheers,
meta

private_meta wrote:

In my opinion, just because you cannot CHANGE anything on the remote side (transfer, filename change, ...) does not justify blocking the user from doing anything entirely.

That's true. Actually if I was to design WinSCP today, I would do it this way. But unfortunately WinSCP is not designed to operate this way :-(
And redesign would be too costly to justify the little gain of possibility to browse local size, changing preferences, and similar tasks.

Well, Of course you cannot do anything involving commands on the remote side, but the way it is implemented currently makes it impossible to do anything. There'd be all kinds to be done in the window, like browsing through the local side, selecting files, changing preferences or modifying the GUI (Toolbars, etc.), moving/resizing the window. Some of that stuff seems to be pointless, but it would add to the usability.

In my opinion, just because you cannot CHANGE anything on the remote side (transfer, filename change, ...) does not justify blocking the user from doing anything entirely.

IMHO, you cannot do anything else with the FTP session while transferring file, so what would the WinSCP window be good for?

Hi,

It's a confusing topic, sorry, I'll try to explain:

I know a lot of FTP-Servers that restrict sessions to one connection per IP. The "Copying"-Window though blocks the entire program, so you cannot do anything without either opening another instance of WinSCP or having a second session and doing a background transfer.

If there is only 1 session possible, it will query for a password every time, as the session cannot connect, and delete the entry out of the queue if it is still not possible to connect.

In my opinion, it would be handy to do background transfers even if there is only one available session, using the current session for transfer. This would make it impossible to browse the directory until either a new session is free or the transfer is finished.

It would be interesting, again in my opinion, because of these reasons:
- There is a possibility to set background transfer as default. With a lot of opportunities existing where this just doesn't work the way it is, it can be annoying
- It is not possible to close the current browsing session to still enable background transfer on one session only
- It would be a handy fallback and it would make the usage more comfortable (the copying-window which blocks the entire app is slightly uncomfortable)

cheers,
meta