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: Fixed

Thanks for your feedback!
guest6481

Fixed

Works as desired [both ways].
martin

Thanks. I'll test it with FTP.
guest6481

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.
guest6481

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.
martin

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?
guest6481

edit

Current version (just downloaded today) 5.21.5

Bug found on following OS: Windows: 2000, XP, Vista, 10, and 11.
guest6481

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.