Bug: program timeout when moving/copying large remote files

Advertisement

bronco
Joined:
Posts:
2

Bug: program timeout when moving/copying large remote files

Hi there,

Client: WinSCP 4.0.6, Win XP Prof., Explorer-like interface,
SFTP (with or without SCP fallback)
Server: Linux, vsftpd

when moving or copying files via drag and drop on the remote site within the same
file system and a file size of something above 1 gigabyte or so, the progress bar
doesn't move (stays at 0%) and the connection timeout occurs after some time, but
the files get moved/copied completely.

Bug or configuration problem?
Thanks!

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

Re: Bug: program timeout when moving/copying large remote files

Do you mean that the prompt "server did not responses for ... seconds" appear? It should disappear once the operation finishes (it may simply last too long).

For the progress bar: duplicating/moving remote files within remote file system is atomic operation from WinSCP point of view. Hence it cannot show progress. The bar make any sense, only if you work with multiple files.

Reply with quote

bronco
Joined:
Posts:
2

atomic remote operations - why timeout necessary?

Hi,

yeah, I exactly meant that prompt "server did not responses for...". Any chance to
change that timeout or some other "workaround"?
The progress bar subject is understood, but as if you know that remote copy and
move functions are treated as atomic operations, why is there any kind of timeout
implemented?
My operators here get a little bit nervous when any kind of error message comes up... ;-)

Thanks is advance!
bronco

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

Re: atomic remote operations - why timeout necessary?

bronco wrote:

yeah, I exactly meant that prompt "server did not responses for...". Any chance to
change that timeout or some other "workaround"?
Please read documentation.

The progress bar subject is understood, but as if you know that remote copy and
move functions are treated as atomic operations, why is there any kind of timeout
implemented?
The fact it is atomic does not mean it cannot go wrong (endless).

Reply with quote

Advertisement

You can post new topics in this forum