Renaming File from Parent Data loses new attachment and doesn't clean up old

l. Add an attachment named 12.Smith_Handbook CA[1].pdf to an item
2. Right-click > Rename File from Parent Metadata
3. Double-click to open: you get "Attachment file could not be found"

Looking in the file system, this is what happened:
a. A new attachment, properly renamed, was created in a new folder
b. This was not linked to the item, though clicking "Locate..." does point you to the right (new) folder.
c. The old unrenamed attachment still exists in its old folder.

Result: unlinked attachments, duplicate files, and general confusion.
I suspect this has to do with something about the filename, but I have not investigated what exactly. For files with less outlandish file names the rename feature has never been a problem.
  • Report ID? Works fine for me.
  • I have also observed (almost) the same behavior on several occasions - lately especially with .xps files. (the difference has been that I have not gotten duplicate files - the only problem is that the attachment in Zotero is not updated)
  • Again, we'd need a Report ID to do anything about this.
  • The Report ID is: 1264259633
  • That doesn't show any errors. Did you generate that after reproducing the error? If you can, provide a Debug ID for a rename attempt that triggers this.
  • It happened again and I made a Debug ID:
    The Debug ID is D1285279121

    I haven't restarted Zotero, so maybe it is in a 'mode' where this happens. I expect it will be OK if I restart.
  • That debug output just shows an attempt to open a file (called "a.pdf"). It doesn't cover the actual renaming attempt, which is what we'd need to see.
  • The problem is that the behavior is unpredictable and irregular - more often than not it works - so it's hard to reproduce
Sign In or Register to comment.