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.
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.
Another way (perhaps the simplest way) to solve this is to resume if time=newer, but is this really what you intended?
Edited by Kukac, 18 January 2007 - 04:11 AM.