Keep File Time and resuming downloads

Hi!

SmartFTP version : 2.0.1001.9

I noticed that the time data of downloaded files (with the keep file time option set) are set to match the server's times only after the download has finished. Files are created with currrent time data, and even if the download is stopped the time values remain the same, ie. not equal to the file's server time.

Why is this not OK? Because there're occasions when I want to resume a download hours or days after I stopped it, and I don't want the partially finished file overwritten. How do you configure this in current versions? Either set an enormously high 'recent' time (to match the time=recent rule in file exists settings) or ignore file time altogether. The file=equal comparison will never be true for a partial download as file times are not yet set.

I believe that this behaviour is illogical, and the time=equal option should cover this case: if the file on the server has not been changed then file times should match even for partial downloads. Therefore file times should be set either right at the beginning or at least when the download is stopped. If a download is aborted in a way that the end of the file might contain invalid data (is there any possibility for that?), the rollback option and later checksum checks should be able to deal with this situtation.

Perhaps I misunderstood something about the 'file exists' rules or there's a way which I haven't discovered to provide the functionality I'm looking for, in this case I'd be happy to be corrected.

Edit:
I know how to configure smartftp to circumvent this problem, so please don't post such suggestions. I had to learn how to after the repeated loss of GB large partial downloads got too irritating. The issue here is that I don't think that the current behaviour is correct.

Edit2:
Another way (perhaps the simplest way) to solve this is to resume if time=newer, but is this really what you intended?

Thank you for your feedback. You have good points and I agree with you that the current behavior is not optimal.

>Set File Time (MDTM) for failed/aborted transfers
We have previously set the file time if the transfer failed or was aborted by the user (stop of transfer queue or close of application). But there is at least one problem:
Aborting transfers by sending the ABOR command is extremely unreliable. There are several reasons for that: The firewall/NAT router between the client and server has already closed the control connection (99% of the case). The server is just not able to abort the transfer correctly. As a result: To send the MDTM command the client needs to reconnect to the FTP server. Also before the client can detect that the control connection has been closed it needs to wait for the timeout (30 - 60 seconds).
Now the intention of most users when closing the application or pressing the Stop button in the Transfer Queue is to immediately stop all transfers without waiting for the timeout and the subsequent MDTM command. We had a lot of reports from users who claimed that the Transfer Queue didn't stop immediately or SmartFTP stayed in the memory. Thus we changed the previous behavior.

>Files are not resumed after some hours/days.
I'm also aware of the problem that the files that are no resumed after some hours or days. If the server doesn't support the file integrity check commands (XCRC, XMD5, etc) the file will be overwritten with the default file exist rules. One of the main reason - as you correctly noticed - is the problem described above.

As I honestly don't have a good idea how to solve this particular issue, I would like to ask you about your suggestions.

Thank you for your time.
-Mat

Hello again ...

I just noticed that I my answer only considered uploads. For downloads the story is slightly different. You are right we didn't set the file time if the transfer was aborted. The reason is because we send a MDTM command to get the file time of the remote file because the last write time of the remote file may have changed during the download. Then we set the local file time. Due to the problem described in my last post we didn't send the MDTM to get the time and thus we didn't set the file time of the local file.
Now I have changed the behavior. If downloads are aborted the file time of the local file will be set if the remote file time is known. In this case SmartFTP will use the remote file time it got at the beginning of the transfer.

Please test it with the latest version:
https://www.smartftp.com/download

Regards,
-Mat