WinSCP DELETES files instead of giving "file not found" warnings (since 4.1.3 and possibly before)

Advertisement

guest6481
Joined:
Posts:
12

WinSCP DELETES files instead of giving "file not found" warnings (since 4.1.3 and possibly before)

Proof of concept:

set for background transfers, 2 concurrent background transfers

using: F6 (move / copy-and-delete)

BUFFER TO TRANSFER: remote --> local

Buffer: 1.txt (242,335 bytes)
Buffer: 2.txt (38,834 bytes)
Buffer: 1.txt (242,335 bytes) AGAIN (finger slip, or just lost track amongst a long list of files)

When the transfer comes to the second 1.txt it will open the write file, THEN discover the source doesn't exist (was deleted after the first transfer), throw the "not found" error. However, the ZERO BYTE file remains! Now, the file is gone from both sides!!

Don't delete this with the advice "just go up one folder level, and move the whole folder." I don't to do that. I should be able to move individual files as I want without them being destroyed! If I want the whole folder, I'll SELECT the whole folder!!

No attachment necessary; would not help. A zero byte doesn't make sense without the above text.

I've lost important pictures because of this bug over the years! This is the THIRD time I've reported this to you. Uninstalling and deleting backup of installer.

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
41,441
Location:
Prague, Czechia

Re: WinSCP DELETES files instead of giving "file not found" warnings (since 4.1.3 and possibly before)

What protocol are you using? I just tested this with SFTP and I cannot reproduce it. Can you post session log file?

Reply with quote

guest6481
Joined:
Posts:
12

I'll get back to you. I'm trying transfer 14 TB from a recovered drive. turning logging has gummed up everything (thanks a lot for that boobytrap) with "session upkeep" messages. I'll have to start everything all over again...

I'll check it tomorrow.

I don't use any funny settings; it's normal FTP [port 21, no encryption].

Every version of your product has done this since I first discovered version 4.1.3.

Reply with quote

guest6481
Joined:
Posts:
12

logs.

the connection broke a few times.
end result is as I said:

when it tried to transfer the second copies, it OPENED a zero byte file, running over the previously successful transfer of the same file.

I don't know why you couldn't duplicate it; I've been dealing with it for years.

just change the protocol: don't open the target file until you verify the source's existence first. can't assume the file exists after being queued.

Reply with quote

Advertisement

Advertisement

You can post new topics in this forum