[Solved] Error 0x80520012 when synching downstream, no *.lnk file found

devash
Hi all,

I just encountered the error 0x80520012 which prevents me from syncing.

The debug Ids are: 1478589025, 78230587

What I did:

I have two computers, cw (computer @ work) and cp (computer @ private)
This afternoon I upgraded on cw Firefox to # 20 and Zotero to 4.01. Then I synched without problems.
Now I have upgraded cp to Zotero 4.01 as well. When I tried to sync cp Zotero gave me the above error.

What I tried to solve the problem.

When looking at the data repository of cw I did not find any *.lnk files (as mentioned in some posts) but occasionally some strange looking files like
2468b3daQ2FWWWw1nkQ25Q5BnzWQ25wnQ7B,Q3ATvz3n_Q5DvQ7DQ3BwQ3BQ7CQ5BQ2FQ3BArw4Q2FQ7C2Q7D2r.

Searching the data repository of cp did not yiel any *.lnk files, either.

When looking at the webdav server for the files, each entry I added earlier today has some *.prop and some *.zip file, so the data seems at least to be at the webdav server.

Emptying the trash on cp did not help, either.

Any ideas what else I could try (short of downloading the complete repository, which may not work, either)?

Thanks in advance.
  • dstillman
    [JavaScript Error: "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.fileSize]" {file: "chrome://zotero/content/xpcom/attachments.js" line: 1112}]
    Can you provide a Debug ID for a file sync that produces this error? (What you provided are Report IDs.)
  • devash
    ah, sorry for the mix up. I've just uploaded D1648265248 (and D695260557).

    If I interpret the log correct then the entry 7GCP5XST causes the error. Which is strange, because this entry has been added May 23rd 2012 and has been synchronized since then without problems.

    The entry 7GCP5XST does contain strange filenames like this one:
    C:\Users\....\.........\zotero\storage\7GCP5XST\aaaabplan3a4nn2isklmmkshhdbycvgiyiro4ao1hqyi2cds1r0yaeznbjubwnpccwm4kbbro99sttr6jgygfcjdlsgwflqgfv01iugezukzdwcmc2votjmxdaefkpooj5i+evmmi40rieqmhxsgxtt7reikhbwhpjv3xeitunq7qns7wtdspbzzpi1kzc9hqji2xvht1hclpjdtxueaow==

    The complete path is 265 characters long and can't be edited properly with the Windows explorer (on Win 7 64bit. Btw, TotalCommander can, that's how I copied it).

    The entry is a Wikipedia entry and the file starts with "GIF89a".

    The questions for me are now:
    * Why did this error surface after nearly one year?
    * Do I need to check all storage directories for these files?
  • dstillman
    What happens if you delete that file? (You can also move it elsewhere, rename it to have a .gif extension, and look at it. I'd be curious to know what it is. Usually files like those are advertising files, but that shouldn't be the case on Wikipedia.)

    As for why it's occurring now, it might be due to some rechecking that Zotero 4.0 is doing to make sure everything is sync. It could also happen if you switched file sync modes, or if you did something that changed the modification times of files within the 'storage' directory within your Zotero data directory.

    Do you shouldn't need to check all directories, but it's not impossible that there'll be similar errors for other files once you clear this one. (I think we're also better now about avoiding these files when saving snapshots, though there might still be some issues.)
  • dstillman
    You can also try the 4.0 Branch dev XPI, which will ignore this error, though it might just fail at a later point in the sync.
  • devash
    As for the gif: I just checked it, it is a ajax spinner animation, see http://www.ajaxload.info and select "indicator big", then you'll get such an image.

    I think it's ok that wikipedia has such an spinning wheel, zotero.org has some, too.

    I did a quick check of all my entry directories as well. Result: I have 16 files in 16 directories/entries (out of 3847 directories/entries) with a path length > 255. 13 of them being the spinning animation.

    So this could be a problem for other users as well, especially as the explorer is not all to cooperative in handling these files.

    I did a path comparison of the storage directories of the two computers:

    cw: d:\........\data\zotero\storage
    cp: C:\Users\....\.........\zotero\storage

    The path at cw is seven characters shorter than the one at cp.

    Maybe that could add to the problem as well?

    Regarding the synch modes: I did nothing unusual (like resetting the synch or something like that). I just pressed the synch button on both computers.

    And I didn't touch the modification times of these - at least not on purpose. The dates are on both machines the same, May 2012.
  • devash
    Just for closure: After deleting all files whose path length was >255 characters, synching commenced normally.

    Although I think the storage directories are now in a slightly inconsistent state (long path files being in one storage and not in the other), I can live with that.

    So for me this issue can be marked as closed.
Sign In or Register to comment.