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

mark
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.
  • dstillman
    Report ID? Works fine for me.
  • pet1202
    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)
  • dstillman
    Again, we'd need a Report ID to do anything about this.
  • pet1202
    The Report ID is: 1264259633
  • dstillman
    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.
  • pet1202
    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.
  • dstillman
    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.
  • pet1202
    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.