Attachment Rename Bug: Metadata Retrieval Renames Files to 'PDF' or 'EBOOK

**Issue:** In Zotero version 7.0.0-beta.97+b899fc9d4 (64-bit) on Windows 11, when right-clicking on an attachment and selecting "Retrieve Metadata," the attachment is renamed to "PDF" (for PDFs) or "EBOOK" (for EPUB files).

**Problem:** Renaming these files using "Rename File from Parent Metadata" updates the linked files correctly but does not change the attachment names in the library view; they remain as "PDF" or "EBOOK."

**Expected Behavior:** The attachments should reflect the actual file names in the library view.

**Reference:** See the included screenshot (Image.png) for visual context.

https://s3.amazonaws.com/zotero.org/images/forums/u14577105/x8ns7kj5bb8syhzyg3kp.png
  • edited 10 days ago
    In the previous beta versions (and also Zotero 6), renaming did not only rename the filename but also the attachment title, which is much more convenient and should imo be still the case. So +1 to expected behavior as described above.
  • Thanks for your response @dstillman and the included link pointing out that this is by design. This certainly isn't a major issue, but I don't agree with the stated rationale for this behavior being to facilitate "less-distracting attachment titles." Unless the user twirls the item open the attachment title isn't seen. And when they do, there's usually a reason for it. Metadata like "PDF" or "EPUB" or "Accepted Version" or "Submitted Version" may be more elegantly presented as the user hovers the item. Perhaps future iterations might include an option to change that behavior. Thanks for all the hard work and dedication that goes into developing a fantastic tool like Zotero.
  • edited 10 days ago
    I have to say I agree with the OP and the other previous commentator and that I don't think the recent change in re-naming practice of attachments is to be welcomed.

    My use case is one of attaching linked files, which are named according to a local convention that Zotero's internal re-naming scheme can't replicate, afaik.

    In Z6, iirc, I used to edit the attachment title and enable the option to rename the attached file, which could then be moved using Zotfile.

    In Z7 the flow was somewhat reversed, with the attachment title taking on the name of the attached file; this worked well enough (with the file now being moved using the attanger add-on).

    The advantage to me of the previous behaviour was that I could see at a glance if I had selected the wrong file to attach; in addition, the name generally was also informative in itself. Going forward, all of my attachments will proudly display their content-encoding in their attachment titles, which is virtually meaningless. It's a bit like having most of your children called PDF (apart from the unfortunate EPUB).

    However: this is only true for the first attachment as subsequent attachments acquire an attachment title which is the same as the attached file, minus the file-type extension.

    And this can lead to absurd results with the first volume of a thesis being 'PDF'
    with the second having a meaningful handle (e.g. Sextus the Sixth - A Review of Roman Naming Practices, Volume 2).

    I have in fact read the long discussion at https://github.com/zotero/zotero/issues/4211, and do not seek to trivialise the issues, but I would urge consideration of allowing back the previous behaviour in some way, perhaps via some option in the settings or else by using different practices for different sources, e.g. pre-existent files, as in this case.

    Thank you!

  • edited 10 days ago
    +1 I have the same issue.

    It seems that in the middle panel we see the name "PDF". But when I check the file name in my Finder/Explorer the PDF name rule is applied. Also, when I open the PDF using Zotero, the name in the tab is shown correctly as the ranamed PDF. Thus, the problem may be only in the name displayed within the Item as @P4R4D0X shown in the image.

    https://s3.amazonaws.com/zotero.org/images/forums/u1957994/to4e5n29je6jt713avuf.png
    https://s3.amazonaws.com/zotero.org/images/forums/u1957994/5uegn79cypc2myzrkzq3.png
    https://s3.amazonaws.com/zotero.org/images/forums/u1957994/qge235r7ijfm8is3229v.png
  • edited 10 days ago
    In the previous beta versions (and also Zotero 6), renaming did not only rename the filename but also the attachment title
    For about a year, Zotero 7 hasn't changed the attachment title when doing a manual Rename File from Parent Metadata if the title didn't already match the filename. We made two additional changes in the latest beta:
    1. We now set the title of the first attachment of a given type to "PDF" or "EPUB" instead of the filename when dragging a file from the filesystem or creating a parent item based on metadata. Subsequent files added to an item will still get titles named after the filename (without the file extension), since those are likely to be supplementary files and the filename may be informative.
    2. We no longer change the attachment title when manually using Rename File from Parent Metadata even when the title matches the filename. If you want to change the title, you can do that from the item pane.
    The impetus for all of this is to avoid cluttering the items list and search results with a redundant line of metadata for every item. Attachments saved from the web have always had titles like "ScienceDirect Full Text PDF", and files have always been automatically named after parent metadata.

    People who were using ZotFile or who were unnecessarily running Rename File from Parent Metadata on every attachment (which used to change the titles of attachment saved from the web like "ScienceDirect Full Text PDF" to match the filename, which was a bug) might be used to seeing filenames in the items list, but we'd encourage people to give the new behavior a try. It will be possible to change existing titles via batch editing in a future version.
    I don't agree with the stated rationale for this behavior being to facilitate "less-distracting attachment titles." Unless the user twirls the item open the attachment title isn't seen.
    @P4R4D0X: That's not the case. Parent items are auto-expanded when a child item matches a search. So with attachment titles matching filenames, you have this distracting duplication of the parent metadata and the attachment itself matches the search and expands the parent, for no reason, every time you search for a title or author in All Fields & Tags mode or an advanced search.
    The advantage to me of the previous behaviour was that I could see at a glance if I had selected the wrong file to attach
    @ajb59: I wouldn't really recommend a workflow where you're manually dragging in files all the time, but you can always see the filename in the item pane for the attachment.
    Going forward, all of my attachments will proudly display their content-encoding in their attachment titles, which is virtually meaningless.
    @ajb59: That's fair in general, but it's just not really true in the context of Zotero, because in Zotero most people have PDFs (and now EPUBs) and snapshots, and "PDF" functionally means the full text. Technically "Full Text" would be the format-agnostic title, but we can't do that automatically outside of a translator where we know what's being added (and in that case we do include "Full Text" in the title).
    However: this is only true for the first attachment as subsequent attachments acquire an attachment title which is the same as the attached file, minus the file-type extension.

    And this can lead to absurd results with the first volume of a thesis being 'PDF'
    with the second having a meaningful handle (e.g. Sextus the Sixth - A Review of Roman Naming Practices, Volume 2).
    Multi-part publications saved from the web will have appropriate titles. If you're adding multiple child attachments locally, you would need to change the first one back to an appropriate title in the item pane, yes, but that's not a problem most people are going to encounter very often.

    @Luis_Claveria: You're misunderstanding the basic point here. Read the linked documentation section to understand the difference between attachment titles and filenames. You can see the filename right in the item pane — you don't need to look at the filesystem.
  • Thank you @dstillman for your careful consideration and response to the comments in this discussion.

    I appreciate the points you make in support of the recent changes but look forward to being able to change existing attachment titles via batch-editing.
  • For about a year, Zotero 7 hasn't changed the attachment title when doing a manual Rename File from Parent Metadata if the title didn't already match the filename.
    People who were using ZotFile or who were unnecessarily running Rename File from Parent Metadata on every attachment (which used to change the titles of attachment saved from the web like "ScienceDirect Full Text PDF" to match the filename, which was a bug) might be used to seeing filenames in the items list
    Then I was used to using the bug. I thought it was a feature, not a bug.

    I understand the explanation for the reason behind the title/filename distinction and I agree that this might be helpful if dealing with multiple attachments for one parent item but as this is such a rare case I really think that the default should be the other way round, so that if it is just one attachment the attachment title should be the same as the file name and if there are more attachments then those can have a different title.

    If it will soon be possible to change the title to be the same as the file name via batch editing this might be not as convenient as the former bug but hopefully at least not to stiff.
  • As a user since 2008, I will chime in to make the point that this critique to the current scheme is not universal among the userbase:
    if dealing with multiple attachments for one parent item but as this is such a rare case
    This is not rare. In my field, every manuscript comes with multiple files now (and the majority of all current literature is in biomedical sciences, so not rare at all). Usually at least a main manuscript file and supplementary data and/or methods file(s). I am looking forward to Zotero saving the supplemental files automatically (which does not happen now), when/if the webpage makes them available.

    We also now have Submitted Articles, Accepted Articles, and Preprints - those are actually important for me to know. I don't need to open the files or hover over them to see what type of files these are.

    On the other hand, I don't see why I would need to know or see a filename. The relevant metadata (author, journal name, year or more) are literally just one line above it in the main pane. I admit that I don't know every workflow, so there may be some other purpose.
  • why do I need to see the filename?

    For example to find duplicates

    In my opinion this change cries for a setting somewhere - not matter how complicated it would be to change that setting: please let the user choose ...

    Even when dealing with multiple documents I would like to simply choose a file with a name to be opened when double clicking the meta-data.
  • to add: I know the duplicate finder but does it find duplicates with different names?
  • edited 8 days ago
    Hopefully, it is acceptable to post this.

    Here are two scripts for the Actions and Tags plugin

    The first script renames both Attachment Titles and Filenames based on the File Renaming format defined in the settings. Select the items or attachments that you want to rename and trigger the script.

    https://github.com/windingwind/zotero-actions-tags/discussions/291#discussioncomment-10034952

    Alternatively, the second script simply renames the Attachment Title to match the Attachment Filename.

    https://github.com/windingwind/zotero-actions-tags/discussions/291#discussioncomment-10035114

    https://s3.amazonaws.com/zotero.org/images/forums/u2014255/tee2b1pf3j29250t9315.png
Sign In or Register to comment.