[MLZ] Error ID 2054807469 file editing denied for group

duncdrum
This error has come up after i noticed that my attachments im my library weren't synced properly. I had to reset sync history to get sync going again, but now this is popping up. As far as i can tell nothing should be going on in the Group library mentioned by the error report.

Any MLZ users experiencing similar problems, there seems to be something with Zotero 4.0.4 has this problem been propagated to MLZ?
  • dstillman
    Can you provide a Debug ID for a sync attempt that's triggering this?
  • dstillman
    edited April 27, 2013
    Well, the problem here is that you somehow were able to edit files in groups that shouldn't allow you to edit files, since you're not a group admin. This could be a bug in the official version of Zotero, but until we get a report of this with that I'm not going to spend much time debugging this. If you upload your database to the DB Repair Tool and provide the Upload ID here, though, I'll take a quick look. (You can ignore the repaired DB returned by the tool, which is unlikely to fix anything.)

    Alternatively, a Restore from Zotero Server would likely fix this, though you'd lose any local changes you've made since the last sync. You could also probably leave and re-join the groups in question, syncing in between.
  • fbennett
    @duncdrum: As Dan says.

    Dan: I'll follow up on this. Is it known what type of file editing has triggered the error (adding/removing an attachment, changing attachment metadata, or editing the underlying file)?
  • dstillman
    edited April 27, 2013
    It looks like an attempt to upload a modification to a PDF. There's a decent chance this is a bug in Zotero 4.0, but debugging this with an MLZ install may be tough. I'll try to reproduce this with the official version, though.

    duncdrum: I'll still take a Debug ID for a sync attempt and an Upload ID from the DB Repair Tool. Also, if you open your Zotero data directory and look in the storage/CJFWRQ5G directory, what's the modification time of the PDF there?

    fbennett: duncdrunm can't install the official version because of the schema changes, right?
  • fbennett
    Dan: Yes. The current database is bound to MLZ, unfortunately. The account can be synced to a separate Zotero install, though I'm not sure that would be helpful for debugging.
  • duncdrum
    Thank you Dan and Frank for your quick help. Here is what i found:

    Debug ID: D40579224

    The pdf was created, last modified, and last opened on Feb 1, 2010 2:32.

    Just to clarify a few things. I have not tried to edit anything in the group mentioned by the sync error. I hadn't interacted with those items for months.

    I noticed odd behavior when my files weren't synced, without any sync errors. The attachments appear in Zotero, but there are no files. It took me about 2-3 days to realize that this was going on.

    After reseting sync on all (1x laptop + 1x pc) machines. The files seem to be syncing again properly, but i keep getting this error on my Laptop.

    Once more thank you for the quick help .
  • fbennett
    I've spent an interesting evening with MLZ in my own account, which reported a large number of seemingly erroneous conflicts upon sync. After those were cleared, it then uploaded a large number of files (including 2GB of data to a group I share with a supervisee).

    In the course of the proceedings, I identified what I think is the cause in my case: the timestamp was being reset on all items with multilingual content. This might be appropriate on the first upgrade to the latest MLZ series (since earlier versions did not sync multilingual fields), but it clearly should not happen on subsequent upgrades, and I will make sure to tame it in the next MLZ release.

    For Dan:

    I also noticed something in my own database: one group was flagged editable=0 and filesEditable=1. Would I be right to think that that setting should never be possible? Or is there a use case in which it would be sane? (If the setting is clearly wrong, I would assume that a flaw in MLZ let it in, not code propagated from Zotero.)
  • dstillman
    OK, I believe I've fixed this, but Frank will have to incorporate the changes into MLZ before you can test it. The problem stemmed from a brief server issue a couple years ago (with file modification times being maxed out on 32-bit servers) and a bug in the current Zotero code that had it trying to correct the problem even if you didn't have file editing access to the library.
    I also noticed something in my own database: one group was flagged editable=0 and filesEditable=1. Would I be right to think that that setting should never be possible?
    From an API perspective, yes. In the DB, it doesn't really matter. This happens in mainline Zotero too. We don't clear the filesEditable setting on the server when you change editable, and the new metadata gets synced down as is. I think in most places we check editable before filesEditable anyway, so this probably isn't a problem, but for good measure I've made filesEditable return false if editable is false. Thanks.
  • fbennett
    Thanks very much for this, Dan! I'll merge the latest changes from the 4.0 branch later today.
  • duncdrum
    Updated to mlz 354 but the error message remains. Not sure why, current error ID 145637057
  • fbennett
    @duncdrum,

    The m354 release doesn't yet contain Dan's new code. The next revision will be coming up soon.
  • fbennett
    duncdrum: I've just put up a fresh MLZ release (4.0m355), which incorporates the new code. It also fixes up a lurking issue with creators in some multilingual libraries. The release announcement is here. Let us know how it does with your attachment item.
  • duncdrum
    hi fbennet, 355 solved the sync errors, and runs smoothly. Thank you for the update.
  • fbennett
    That's great to hear! Thanks for reporting back.
Sign In or Register to comment.