File sync, status and unnecessary transfers (?)

zotero sync 3.2 is working well for me - I have just updated my reference library to ~1000 entries, with about 80% having attached PDFs totalling ~1GB. I am using S3/Jungle Disk for storage. So far so good!

However, something is a little odd. For example I uploaded several hundred new entries from work yesterday, which synced to the server fine. This morning I switched on my home PC and zotero downloaded all of the new entries - perfect, although the download status keeps jumping back from 99% to something less.

Anyway, on the next sync the home client began to *upload* a large chunk of data - when both clients should be perfectly in sync at this point. As I type the home client is at ~600% progress with -1700000KB left to transfer :-s

The bandwidth costs are not so high that I worry at the moment, but if this becomes a regular thing... Any suggestions welcome!
  • There are a few kinks to work out in the progress display, as you noticed.

    You can start Zotero with debug output and then send the output for the erroneous transfer (or the beginning of it, if you interrupt it) to, and we'll take a look.
  • I have sent the log (or part of it) by email as suggested, with subject:

    "Perpetual upload/download problem (zotero 1.5-sync3.2)"

    Please let me know if you need any more info etc. to assist!
  • Are there any errors in Report Errors after any of the syncs? If so, send in an error report and post the Report ID here.

    Could you also send a bit of output from a download sync? For some reason, at upload time, the modification time of the previously downloaded files don't match the times in the database that are stored when the files are downloaded, so Zotero thinks the files have been updated locally and need to be uploaded.
  • My first client doesn't have any errors, and also has fewer problems staying in sync. The second client (the fresh client that did the first large download), however, has a stack of "no element found" errors for many of the .prop files.

    As requested, I have sent another log file (same email; subject), this time from the first client, showing both uploads and downloads. Although this client "sorts it self out" rather quickly. This (1st) was in sync yesterday. This morning the 2nd was trying to upload again. I let it run through some of the entries before I had to shut it down. The first client, however, is *not* trying to download again.

    Again, please let me know how else I can help!
  • Would this have anything to do with not being able to sync one side? I followed the one-side directions. I got everything loaded in my jungledisk file on one side (I was getting 398%, etc.) That's fine and working great.

    Problem: the other side won't download the files in storage. If I add something to side 2, it will sync fine and I can see the folder in the storage file. However, the files in storage from the side 1 sync will not download to side 2.

    I have even gone so far as to uninstall firefox and reinstall everything. I am running Firefox 3.03, Zotero v1.5-sync3.2. I will send the console output, however, it has an obvious line it: "No files to download"
  • Quick update - client 2 is now saying:

    "Conflict! Last known mod time does not match remote time!"

    Error report submitted as: 669633392

    tmedney: it sounds like you have a different problem - I get everything synced on both sides correctly, initially. Then the second side seems to mess up the timestamps somehow and tries to upload existing files repeatedly.
  • Update: in case this was just a JungleDisk problem, I started afresh with First upload (client 1) and download (client 2) were successful.

    Client 1 shows no file activity on next sync. Client 2 tries to upload large amounts of data.

    So the same problem on both WebDAV services.
  • We'll need new debug output from the second side, then. (You can interrupt it in the middle of the upload if you want.) The last debug output you sent simply had an "Invalid login/pass" error for the sync server (as you noticed). Storage sync gets its list of files to download from the sync server, so if it can't connect to the sync server, it won't download anything.
  • Some of the progress meter problems during uploads should be fixed in Sync Preview 3.3, now available. (They were caused by bugs in Firefox 3.0 that will be fixed in Firefox 3.1. The meter may still be a little jumpy, but not quite so far outside the realm of, say, basic math.)

    Download progress will still keep jumping back from ~99%, as we're not yet calculating the total file size of all queued downloads before starting the initial ones.
  • Thanks for the response. I have updated to 3.3, and the sync problem is the same - I have just emailed a debug log as requested for client 2.

    At this time, client 1 has uploaded new items to the server today (again, client 1 functions perfectly). Client 2 does not download these new items, but does again try to upload (although I aborted before it could finish).
  • A quick update/question - I noticed today that my two versions of firefox/zotero show dates in different formats (one UK, one US). Just wondering if somehow this was affecting the date/time stamps and causing the sync problems? I guess firefox is set to different locales on my two machines...
  • I don't believe that should matter. It looks like the problem isn't actually a difference of the timestamps between two computers—rather, it's the difference between the timestamp Zotero sets on a file to and the timestamp it receives back when it retrieves it. Obviously those should be identical if the file hasn't changed, but, unfortunately, that doesn't appear to be the case on your system, and so Zotero thinks the file has changed.

    The TZ environmental variable on Windows is known to mess up timezone settings in Firefox, which could potentially cause this problem, but that variable didn't exist on your system, so the problem lies elsewhere.

    Could you try running these two lines of JavaScript and let me know what you're seeing? This may or may not be the same issue.
  • Just in case, I re-installed ff with en-GB locale (so both match), but no change.

    The js code gives 1 (my timezone is GMT+1) and the correct local time.

    Just to check: does display all times in GMT?
  • The js code gives 1 (my timezone is GMT+1) and the correct local time.
    OK, so you're seeing a different issue. Will need to keep working on this one...
    Just to check: does display all times in GMT?
    It currently just displays the time stored in the database, which should be GMT.
Sign In or Register to comment.