I have a 600MB website and am trying to transfer only files that have been edited, or new files.
I select the appropriate option ("transfer only if newer") but this appears to be ignored and the whole 600MB gets transferred. 3 hours...
Is this a bug, or am I doing something wrong?
I have been using Rsync on a previous system but the new one supports SFTP only.
I am using CoreFTP free version. I tried to pay for the full version but the Paypal process fails.
How does one transfer only files which have been changed?
What I am getting is that a file starting with a stamp of say
29/3/2008 08:46
is written to the server as
29/3/2008 00:00
so no wonder that the whole lot gets transferred every time...
I also notice 1 or 2 files written with a zero size.
This was done with the "do not use MDTM" box UNchecked. But with it checked, I get the whole lot transferred also. I wonder if that option is perhaps not doing anything?
The server is SuSE 11.2 with Apache.
I tried it with the above box checked, and with a 2 hour time offset. That, of course, transfers the whole lot every time
"this will only work for binary files, and not text files if the remote server is not Windows based. "
Can one make it work for all files by forcing a binary transfer?
I would appreciate any ideas.
29/3/2008 08:46
is written to the server as
29/3/2008 00:00
so no wonder that the whole lot gets transferred every time...
I also notice 1 or 2 files written with a zero size.
This was done with the "do not use MDTM" box UNchecked. But with it checked, I get the whole lot transferred also. I wonder if that option is perhaps not doing anything?
The server is SuSE 11.2 with Apache.
I tried it with the above box checked, and with a 2 hour time offset. That, of course, transfers the whole lot every time
"this will only work for binary files, and not text files if the remote server is not Windows based. "
Can one make it work for all files by forcing a binary transfer?
I would appreciate any ideas.
I may have found a bug in CoreFTP.
I transfer a file as mentioned above, and the date is transferred OK but the time is set to 00:00.
However if I download the file using a web browser, the time shows correct!!
So CoreFTP is zeroing the time... but only when displaying the file in its directory listing. The decision on whether to transfer e.g. if newer is made on the basis of a correct datestamp.
Apparently, this has to be a bug in CoreFTP because the MDTM command transfers an integer # of seconds, not date/time separately.
I have also just noticed that when doing a big transfer (several thousand files) the timestamp does eventually appear correctly!! So this bug is variable. I have tried all the different date formats but this makes no difference.
I transfer a file as mentioned above, and the date is transferred OK but the time is set to 00:00.
However if I download the file using a web browser, the time shows correct!!
So CoreFTP is zeroing the time... but only when displaying the file in its directory listing. The decision on whether to transfer e.g. if newer is made on the basis of a correct datestamp.
Apparently, this has to be a bug in CoreFTP because the MDTM command transfers an integer # of seconds, not date/time separately.
I have also just noticed that when doing a big transfer (several thousand files) the timestamp does eventually appear correctly!! So this bug is variable. I have tried all the different date formats but this makes no difference.
OK, open up this file
http://www.peter2000.co.uk/hcont.html
and see the date/time. You will see it is
12 October 2008 20:38:33
(from Firefox page properties). This is correct.
If I access the server using CoreFTP, the file shows (in the CFTP directory listing) as
12/10/2008 00:00
and same if I right-click and look at Properties (in the RH window in CFTP).
If you give me your email address I will email you screenshots.
I think it has to be a CFTP bug because the MDTM function transfers # of seconds since 1971 (or whatever) and there is no way to corrupt this so that the date is right but the time is 00:00.
It looks like a display bug in CFTP.
However I am getting some random/ ambiguous results when I try to do a repeated transfer of a file; if the bug was just in CFTP's directory display code then the file should NOT transfer again (if I select 'transfer only if newer') but sometimes it does... Are you comparing the #seconds stamps for equality (which would be wrong) or for greater-than?
Anyway having spent far too much time on this, Monday onwards I will be using rsync so this will be moot, but you may like to fix it.
http://www.peter2000.co.uk/hcont.html
and see the date/time. You will see it is
12 October 2008 20:38:33
(from Firefox page properties). This is correct.
If I access the server using CoreFTP, the file shows (in the CFTP directory listing) as
12/10/2008 00:00
and same if I right-click and look at Properties (in the RH window in CFTP).
If you give me your email address I will email you screenshots.
I think it has to be a CFTP bug because the MDTM function transfers # of seconds since 1971 (or whatever) and there is no way to corrupt this so that the date is right but the time is 00:00.
It looks like a display bug in CFTP.
However I am getting some random/ ambiguous results when I try to do a repeated transfer of a file; if the bug was just in CFTP's directory display code then the file should NOT transfer again (if I select 'transfer only if newer') but sometimes it does... Are you comparing the #seconds stamps for equality (which would be wrong) or for greater-than?
Anyway having spent far too much time on this, Monday onwards I will be using rsync so this will be moot, but you may like to fix it.