Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Re: Background transfers have fewer options than foreground

Anton P. wrote:

I guess it depends on the screen size. At 1024x768 there's lots of room for extra columns. At 800x600 there's less, but perhaps if the columns were optional like those of the directory panel then the user could decide how to manage them. However, I don't think that optional columns are absolutely necessary; the user can resize the columns anyway so if he doesn't like the new one he can squash it down.

I'll see.

Certainly I would be grateful to have this feature implemented "with risks" than wait longer for a risk-free implementation :-)

Unfortunatelly you've missed by few days chance to get this into the next release (coming out tomorrow, if everything goes well).
Anton P.

Re: Background transfers have fewer options than foreground

martin wrote:

Because there is less space to display the items. I can consider replacing "elapsed time" with "time left". Problem is that "time left" may not be always available. What do I display then?

I guess it depends on the screen size. At 1024x768 there's lots of room for extra columns. At 800x600 there's less, but perhaps if the columns were optional like those of the directory panel then the user could decide how to manage them. However, I don't think that optional columns are absolutely necessary; the user can resize the columns anyway so if he doesn't like the new one he can squash it down.

I don't think that elapsed time should be replaced.

martin wrote:

Maybe option "disconnect once queue is empty" can be better approach. What do you think?

That sounds perfect. You may possibly want to include a confirmation dialog (which has an option not to be shown again) to tell the user that the program really will be closed once the queue is empty, even if they are still "in the process of using WinSCP", eg, looking at the screen and just about to change directory or something.

Of course, there are some issues: what might the user be doing when the queue empties and the program tries to close? If he has a dialog open, you wouldn't want the program to exit; instead you would want another dialog to popup saying that exit was cancelled.

What if he was in the middle of navigating through folders etc? Ideally, WinSCP would want to keep a track of user activity and only exit without confirmation if there had been no activity for, say, 10 seconds. But this is getting perhaps over-complicated now; if a user chooses "exit when queue is empty" (which certainly wouldn't be the default!) then he is ultimately responsible for not being in the middle of a task when it does try to exit!

Certainly I would be grateful to have this feature implemented "with risks" than wait longer for a risk-free implementation :-)

martin wrote:

You've missed the very first sentence on the page :-)

Indeed! :-P I also hunted around and found "Not released yet" (https://winscp.net/eng/docs/history). Very useful! Perhaps it should be linked to on the front page, as it's not obvious that this info would be found under "History"!

Best wishes,
Anton
martin

Re: Background transfers have fewer options than foreground ones

Anton P. wrote:

1.) Foreground transfers show "time left" whereas background ones don't. (There's no corresponding column in the queue list.)

Because there is less space to display the items. I can consider replacing "elapsed time" with "time left". Problem is that "time left" may not be always available. What do I display then?

Anton P. wrote:

2.) The speed of background transfers cannot be altered like it can for foreground transfers.

It's on TODO list.

Anton P. wrote:

3.) There is no option to "disconnect when operation finishes" for background transfers.

Regarding your second post, you should have an idea already, that this is quite complex thing to do. Maybe option "disconnect once queue is empty" can be better approach. What do you think?

Anton P. wrote:

On a different note, the page https://winscp.net/eng/docs/ui_queue (Background transfers queue list) talks about options for suspending and resuming transfers, and an "All" submenu for suspending and resuming all. I have never seen these items, either on context menus or on the queue toolbar. (I am using SFTP.) Am I missing something?

You've missed the very first sentence on the page :-)
Note that the documentation may already reflect new features and changes from upcoming release.
Anton P.

Just to clarify my position regarding "disconnect" for background transfers, I understand that the point of a background transfer is that it is backgrounded: it shouldn't interfere with whatever else you're doing.

So ordinarily you wouldn't want it to disconnect your session!

However, I think that it should be possible to override this default, and say "yes, really do disconnect when you're done", so that when you've finished your other WinSCP tasks but a long transfer is still ongoing, you can go for lunch in the knowledge that your session will not be left open indefinitely.
Anton P.

Background transfers have fewer options than foreground ones

Hi Martin,

Less information is available about background transfers than foreground ones.

1.) Foreground transfers show "time left" whereas background ones don't. (There's no corresponding column in the queue list.)

2.) The speed of background transfers cannot be altered like it can for foreground transfers.

3.) There is no option to "disconnect when operation finishes" for background transfers.

I think that any option which is available for foreground transfers should also be available for background ones, and vice-versa (unless there is a technical reason why this cannot be done, eg perhaps (2) above.)

The inability to select "disconnect when operation finishes" for background transfers is pretty annoying, if the transfer turns out to take a lot longer than you anticipate and you want to go for coffee!


On a different note, the page https://winscp.net/eng/docs/ui_queue (Background transfers queue list) talks about options for suspending and resuming transfers, and an "All" submenu for suspending and resuming all. I have never seen these items, either on context menus or on the queue toolbar. (I am using SFTP.) Am I missing something?

Best wishes,
Anton