Synchronize uploads complete site, not just changes

[RussZB]

Since the last update I have uploaded changes to my website twice and each time the size of the the upload was either 1.2 or 1.9 GB, my whole site is only 2.1 GB in size and I only added one video of no more than 200 MB. I have been using Cyber Duck for this site for over a year and I never had this problem before. I go to the site folder on the web server and choose SYNCHRONIZE, as I always do but these last two times it seems like it's trying to upload most of my website and not just the changes.

Thanks

[jeffwhitehurst]

I've noticed this behaviour as well since the last update to Version 4.0.1 (8510). I synchronize (upload only) by directory, and instead of just the new/changed files, every file in the directory gets uploaded. I've been through the preferences and haven't found anything that looks like it's changed.

[dkocher]

Please update to the latest ​snapshot build available and report back if the problem persists. Please include the transcript from the log drawer of the Transfers window.

[dkocher]

Make sure you have enabled the options in Preferences → Transfers → Timestamps.

[jeffwhitehurst]

Transfers log drawer transcript

[jeffwhitehurst]

Sorry to report the problem persists.

I updated to the 4.02 snapshot, and verified that both checkboxes in Preferences > Transfers > Timestamps are selected.

In the local directory I placed a new file, 3.jpg and started the synchronize. Cyberduck checked timestamps, then gave me the confirmation dialog, with Upload selected in the drop-down (which is what I want, upload only) and all the individual files' checkboxes selected (prior to installing v4.01 only some checkboxes were selected). Cyberduck again checked timestamps, and then uploaded every file in the local directory, including those in a subdirectory, rather than just the new file.

Thanks for your help, Jeff

[Marc Saurfelt]

I think there is a problem with the date of the remote file. If you look at the details for a file the transfer window, you'll see that the date of the remote file is completely wrong (see image below). This is not true in the explorer window.

[jeffwhitehurst]

Yes, there seems to be something going on with the date of the remote file. I've attached a screenshot of the local directory listing and the remote file display in CyberDuck, showing both the local and remote files with the same timestamp of Mar 10 2011 12:38. When trying to synchronize, the date in the confirmation dialog displays February 3, 0213 7:34:24 !

[Marc Saurfelt]

Not fixed in 4.0.3

[dkocher]

#5916 closed as duplicate.

[dkocher]

In r8655.

[Davideo]

After the ticket was closed, I am still having the same problem, using 4.0.2 and 10.6.4. The datestamp shown in the Transfer window drawer for the remote site is not the same as is shown in the main window. (The local datestamp is accurate.) This seems to be the cause of syncing all or many more files than were needed. The Timestamp box is checked in Preferences.

[Davideo]

I would have uploaded a screenshot, but couldn't figure out how to do that. The attachments link doesn't seem to be helpful for comments. The help page seems to require a macro, and I just don't have time to get deep into that. In the screenshot, the index.html has a different datestamp than in the Transfer window.

[Davideo]

I then noticed the ToolTips for the Attachments link, which led me to the Attach File button (not a very user-friendly piece of programming), and found that my screenshot of 360 kb was rejected as too big. Well, I tried...

[dkocher]

Replying to Davideo:

After the ticket was closed, I am still having the same problem, using 4.0.2 and 10.6.4. The datestamp shown in the Transfer window drawer for the remote site is not the same as is shown in the main window. (The local datestamp is accurate.) This seems to be the cause of syncing all or many more files than were needed. The Timestamp box is checked in Preferences.

This issue is fixed only in the latest ​beta build available.

[dkocher]

Milestone 4.0.3 deleted

[dkocher]

#6017 closed as duplicate.