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
**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
https://www.zotero.org/support/file_renaming#attachment_title_vs_filename
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!
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
- 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.
- 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. @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. @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. @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). 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.
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.
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.
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.
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.
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
Please let me know if I should open a new issue.
In my case, I do not want my attachments (pdfs, ebooks) to be renamed using metadata. So I have the corresponding option unchecked in zotero preferences. Still when I add an ebook it renames it to Ebook.
This is my version: 7.0.0-beta.103+691d26886
But yes, I actually just noticed the title behavior you describe, and it's arguably a bug. In cases where Zotero doesn't automatically rename the file, it probably should use the base of the original filename (i.e., the part without the extension) as the title. We're already doing that for subsequent files (e.g., the second child PDF of an item), so this would be consistent with that.