problem: "file1" is stored to "file2".zip

[byzantine]

I'm using SFFS 5.06 to backup my files via SFTP.
SFFS encryption crates one "right side" zip file for each "left side" file.

Two strange observations:

- in one directory, the first ca. 30 files contain "wrong" original files, e.g. the "right side" file
IMG_2720.d20100501-u184838.jpg.s4368669.zip
contains the original file
IMG_2721.jpg

- next, there is one zip-file which is not recognized as valid zip (by 7zip; cannot attach corrupt file due to size >2MB)

The rest of files are o.k.
Any explanation for that?

Thanks - Uli

[superflexible]

The only known way where this can happen is if files are renamed. Then the zip files are renamed on the destination side too, but their contents cannot be renamed without a new upload.

Please send the problematic zip file to support@superflexible.com. It would also be beneficial to take a look at the log files from this job.

[byzantine]

Concerning ex post renaming on the "right side", I know I did not rename the files manually, and I cannot imagine some "unknown job" which renames arbitrary file subsets in such a systematic way.

I just sent the sample zip and job log via email.

[superflexible]

Thanks for the files! The zip file looks fine and it can be opened with Power Archiver, for example. I believe that the other bug was recently fixed. Please try the latest version 5.13.

[superflexible]

Apparently there were SSH communication errors causing the problems. I have now released version 5.14 which uses an additional file size check after uploading to SSH. That should rule out most uploading file corruptions. However, to be totally safe, please choose "Verify copied files" on the Files tab sheet.

[superflexible]

An additional precaution would be the option "Automatically resume" on the tab sheet "Files". This uses a temporary filename for uploading and the file will only get the final name if the upload is successful and the uploaded size is correct.

[byzantine]

I tested version 5.14 and did not observe any corrupt zip so far.
But the "filename mismatch" problem persists ("name<i>.zip" contains original file "name<i+1>").
There is a coincidence with SSH exceptions. I sent zip and log samples via email.

[superflexible]

It must be a peculiarity of the Strato server. The next update will close and reconnect the entire SSH connection after these exceptions and thus try to avoid the problem.

[byzantine]

The effect is still present with V5.15.
I switched on "internet logs": the SFFS FTP-log lists hundreds of file transfer failures.
I have sent all logs via e-mail.

[superflexible]

5.15 is not the version with the fix. You tested the wrong version. You will find 5.16 on the web site tomorrow.