Jump to content


Photo

How To Disable Automatic Retry In Queue?


  • Please log in to reply
8 replies to this topic

#1 Schnena

Schnena
  • Members
  • 7 posts

Posted 22 February 2008 - 05:30 AM

Hey,

I have a server that displays encrypted file sizes before transfer and decrypts them on the fly as you transfer them. This is normal behavior, but means the server cannot predict the real file size until a transfer is requested. With SmartFTP, this constantly results in:

[00:27:11] File size mismatch.
[00:27:11] Transfer failed. Use the Transfer Queue for automatic retries.

When I use the transfer queue it just attempts over and over again to retry to the file dl, resulting in it being impossible for me to DL files. And when I don't use queue it just shows that error above and wont let me queue up multiple files. How can I disable automatic retry/disable SIZE check? I've been through the options and read help but I cant find anything about it.

This is a great client (best FTP client I've ever used in fact, just started using it yesterday in Trial mode) and I'll probably buy it if I can use it for my transfers if I can fix this, but w/o a solution to this it becomes virtually unusable. :-\

Transfer log, as I know you guys like that stuff:

[00:49:20] SIZE Testing123.ZIP
[00:49:20] 213 5221626
[00:49:20] MDTM Testing123.ZIP
[00:49:20] 502 Command not implemented.
[00:49:20] Obtaining file information (size/date) from directory listing.
[00:49:20] TYPE A
[00:49:20] 220 Type set to A
[00:49:20] PASV
[00:49:20] 227 Entering Passive Mode (64,34,178,144,11,112)
[00:49:20] Opening data connection to 64.34.178.144 Port: 2928
[00:49:20] LIST -aL
[00:49:20] 2343 bytes transferred. (22.2 KB/s) (103 ms)
[00:49:21] 226 Transfer complete.
[00:49:21] TYPE I
[00:49:21] 220 Type set to I
[00:49:21] PASV
[00:49:21] 227 Entering Passive Mode (61,61,61,6111,181)
[00:49:21] Opening data connection to 61.61.61.61 Port: 2997
[00:49:21] RETR Testing123.ZIP
[00:49:21] 150 Opening data connection.
[00:49:35] 226 Transfer complete.
[00:49:36] 5179644 bytes transferred. (339 KB/s) (00:00:14)
[00:49:36] MDTM Testing123.ZIP
[00:49:36] 502 Command not implemented.
[00:49:36] File size mismatch.
[00:49:36] Transfer failed. Use the Transfer Queue for automatic retries.


Thanks.
- Schnena

Edited by Schnena, 22 February 2008 - 05:54 AM.


#2 mb

mb

    Developer

  • Administrators
  • 11521 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 22 February 2008 - 05:53 AM

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

#3 Schnena

Schnena
  • Members
  • 7 posts

Posted 22 February 2008 - 05:59 AM

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?).

Edited by Schnena, 22 February 2008 - 06:02 AM.


#4 mb

mb

    Developer

  • Administrators
  • 11521 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 22 February 2008 - 06:20 AM

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

#5 Schnena

Schnena
  • Members
  • 7 posts

Posted 22 February 2008 - 06:33 AM

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.

#6 mb

mb

    Developer

  • Administrators
  • 11521 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 22 February 2008 - 07:13 AM

Hello ...

I have implemented it in the latest v3.0 beta version. You can get it from:
http://www.smartftp....oad/SFTPNSI.exe

It should do what you want.

Regards,
Mat

#7 Schnena

Schnena
  • Members
  • 7 posts

Posted 22 February 2008 - 07:49 AM

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.

#8 mb

mb

    Developer

  • Administrators
  • 11521 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 22 February 2008 - 07:53 AM

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

#9 Schnena

Schnena
  • Members
  • 7 posts

Posted 22 February 2008 - 09:39 AM

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


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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users