Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronize uploads complete site, not just changes #5794

Closed
cyberduck opened this issue Mar 17, 2011 · 15 comments
Closed

Synchronize uploads complete site, not just changes #5794

cyberduck opened this issue Mar 17, 2011 · 15 comments
Labels
bug fixed ftp
Milestone

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Mar 17, 2011

f10b63b created the issue

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


Attachments

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 19, 2011

cd777e4 commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 25, 2011

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 25, 2011

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 25, 2011

cd777e4 commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 26, 2011

Marc Saurfelt commented

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.

external image

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 27, 2011

cd777e4 commented

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 !

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 24, 2011

Marc Saurfelt commented

Not fixed in 4.0.3. It is a very annoying bug !

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 2, 2011

@dkocher commented

#5916 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 2, 2011

@dkocher commented

In d6a8e28.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 28, 2011

035e69d commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 28, 2011

035e69d commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 28, 2011

035e69d commented

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...

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 29, 2011

@dkocher commented

Replying to [comment:12 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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jun 2, 2011

@dkocher commented

Milestone 4.0.3 deleted

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jun 20, 2011

@dkocher commented

#6017 closed as duplicate.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed ftp
Projects
None yet
Development

No branches or pull requests

1 participant