How To Disable Automatic Retry In Queue?

Hello ..

Your server setup doesn't allow you to resume a broken file transfer and it's impossible for the client to verify if the file has been transferred correctly. Basically a setup like this is hardly usable outside of an experimental environment. The better way is to decrypt the files after they have been transferred (e.g. PGP) or the server should do everything transparently. It means the original file information (size) need to be returned by the server.

Regards,
Mat

Indeed, I am aware of such shortcomings. Unfortunately the files being transferred are on a SAN and not created by this server, and therefore cannot be decrypted beforehand/stored on the server due to storage constraint.

While drastically suboptimal, the implementation is unfortunately limited by this.

In short, there's no way to "dumb down" SmartFTP so it doesn't *require* file integrity in size? Not trying to insult SmartFTP implementation at all, as I said this is the best client I've used yet (for most setups it would be at least), but if that's the case, it would still be nice to have that as an option rather than an absolute requirement.

If not, are you aware of what the last old version of Smart FTP was that didn't have this constraint (if there was one?).

Hello ..

You can do the following:
1. Go the favorite settings. Then in the Transfer->Files dialog set the "Ignore Error" option to Enable.
2. Then use the direct transfer method.

This way all errors are ignored and SmartFTP will not abort the batch transfer after the first failure.

I hope this is a solution for you.

Regards,
Mat

Hello ..

You can do the following:
1. Go the favorite settings. Then in the Transfer->Files dialog set the "Ignore Error" option to Enable.
2. Then use the direct transfer method.

This way all errors are ignored and SmartFTP will not abort the batch transfer after the first failure.

I hope this is a solution for you.

Regards,
Mat

Sweet, that definitely helps to solve the problem for a single thread. Is there any way to make the "Transfer Queue" replicate this behavior, because even with that checked it still seems to retry the files (reason I want transfer queue is for threaded transfers).

Thanks btw, you've been very helpful so far. Much appreciated.

Hello ...

I have implemented it in the latest v3.0 beta version. You can get it from:
https://www.smartftp.com/download

It should do what you want.

Regards,
Mat

Hey, thanks for the support. You've been very helpful; much appreciated. I will try the new beta immediately (and out of curiosity is there a 64 bit ver of beta compiled too, or only 32?).

As a potential workaround for 2.5, I've discovered that if the file SIZE is smaller than what is actually received, it does not try to re-dl the file. Only when it thinks it didn't receive the whole file (aka SIZE larger than the actual size recv'd) does it re-try to download. As a solution to this I made the daemon send a slightly too-low size based on a "best guess" of the decrypted size, and this appears to be working.

Only the 32-bit version is available of the beta.

Only the 32-bit version is available of the beta.

new beta appears to function properly w/ the change. thank you greatly.