Note that there is default 100 kB limit to enable transfer resuming. If the file was smaller, it won't have the .filepart extension.
Agreed, and I had this 100K limit set. However, I see from the documentation that 'text mode resume' is not supported. I think that this was the problem in my earlier post, as my "foo.tex" file is slightly bigger than 100K---it's a long file!
Is 'text mode resume' unsupported even if you choose "Resume all files (not recommended)" from the resume preferences? Either way, I think that there should be a note on the preferences dialog informing the user of this, and we should make a clarification in the documentation regarding this. Also, could you explain *why* resuming all files is "not recommended"?
It seems to me that the resume functionality is not much use for backup purposes
unless it applies to every file, regardless of size or transfer mode. Without this, if there is an interruption you either have to retransfer the whole job (because the interrupted file might have been a small file, or a text-mode file) or you have to manually search through the remote system using the folder compare feature in order to find the interrupted file (which might be buried deep in the tree being transferred.)
Most importantly, something still seems to be going wrong with the current resume functionality. I have done some tests: I have a file called "foo.dvi" which is bigger than 100K and which will be transferred as binary not as text. If I drag that file across and refresh the remote panel while it is transferring, I can see the .filepart extension, and if I disconnect and then retransfer, WinSCP will ask whether I want to resume. Great!
But here's the problem that (as I now realize) has been affecting me: my "usual" backup job involves me dragging a folder across, not individual files, and "foo.dvi" is inside that folder. If I do not refresh or change directory in the remote panel, obviously I cannot see what extension is being put on the "foo.dvi" file. But if I manually disconnect, I reconnect and enter the remote folder and inspect the file, then
1) it does not have a .filepart extension;
2) its timestamp is set to the transfer time not the Windows timestamp;
3) its permissions are incorrect.
(It has the time of the transfer, not the Windows timestamp; presumably the remote timestamp is modified after transfer has completed, at the same time as the permissions?)
I have then tested by actually refreshing the remote panel and entering the folder while the transfer is taking place, and by doing lots of refreshes I can see that none
of the files inside that folder is being given the .filepart extension as the transfer progresses, even if they are >100K and are binary. So it seems that the resume mechanism is not working inside folders, only at the "top level" of the transfer.