How to batch convert Link to file attachments into copy of file attachment?
Is there a way to batch convert attachments on items that are "Link to file" into "Store Copy of file"?
I migrated from Mendeley, so all my existing items have attachments as "Link to file". I have 500+ items, and I would like Zotero to no longer have a "Link to file", but store a copy that is Zotero internally manages.
I looked into ZotFile, however, I still have not figured out a way to batch convert existing item "Link to file" attachment into copy of file.
I migrated from Mendeley, so all my existing items have attachments as "Link to file". I have 500+ items, and I would like Zotero to no longer have a "Link to file", but store a copy that is Zotero internally manages.
I looked into ZotFile, however, I still have not figured out a way to batch convert existing item "Link to file" attachment into copy of file.
One down side of this method requires to "force" rename the files. What if I don't want to rename the files?
Just out of curiosity, is it a complex task to implement the conversion of links to copies natively in Zotero?
I don't think this would be crazy _complicated_ to implement in Zotero itself, but since there's currently nothing along those lines at all, it would probably a good amount of work, yes.
1) Zotero does not force user to rename the files. Under Edit >> Preferences >> General >> File Handling, I have the ability to disable "Automatically rename attachment files using parent metadata".
2) Can we have the native support in Zotero for converting existing "Link to file" attachment into "Store Copy of file" attachment be put on a wish list or feature request for Zotero?
After migrating from Mendeley, I have over 500+ items with attachments as "link to file". All my future additions to Zotero will be copy of files, but the initial items are still stuck with "link to file" thus I can't take advantage of syncing.
Below are examples of people needing the feature of converting "link to file" into "store copy of file":
https://forums.zotero.org/discussion/34463/convert-linked-file-attachments-to-stored-attachments
https://forums.zotero.org/discussion/9043/automatic-conversion-from-linked-files-to-copied-files
Although ZotFile is a possible temporary work around, it still doesn't properly work due to bugs. Below are some examples of issues:
https://github.com/jlegewie/zotfile/issues/368
https://forums.zotero.org/discussion/comment/316079
We could add an option to store all files, but it would mean losing the folder hierarchy that Mendeley optionally creates. The alternative for someone who wanted to keep that would generally be to install the ZotFile plugin and set it to use that same folder structure. Of course, linked files in Zotero don't sync, so if syncing is more important than the folder structure — which it sounds like is the case for you — you might choose to store files instead.
Yes, I think giving an option to 'store all files' would be helpful so that users can decide if their priority is syncing or maintaining a folder hierarchy of attachments locally. This would benefit first time migrators on how they plan their future use of Zotero, and they don't have to get stuck with portion of their library being 'linked' and a portion being 'stored'.
I understand one can use ZotFile to convert linked attachments to stored attachments. However, based on my experience, ZotFile has an issue with batch conversions. Therefore, after a test migration from Mendeley, I wasn't able to convert all my linked attachments as stored copies.
Previously I preferred to maintain linked attachments so I can have control over my organization and structure. I now prefer to let Zotero store the file so I can use the syncing feature. With zotero-file-hierarchy (thanks to @emilianoheyns ), I can always recovery the attachment folder hierarchy if I ever stop using Zotero.
Everything seemed to have worked out nicely. I set up syncing using my Nextcloud account.
Now on my windows machine I have noticed, that all files werejust linked and not really synced or copied ,because i cannot open any here. I will have to see if I do a completely new import or if one of the suggested workaround works for me.
I just wanted to add, that it would be helpful to give the option to actually import/copy all files using the mendeley import tool, or at least make the user aware, that files are just linked.
If you've already imported from Mendeley, this option won't help (unless you clear your database and reimport), but I'm working on a feature that will allow linked files to be batch-converted to stored files. I'll post here when that's available in the beta, which should be within a few days.
I tested out a fresh import from Mendeley with file handling set to "Copy files". The process ran pretty smooth, but took ~15-30min for ~730 items.
There was one minor issue I came across. After migration, there were few items in My Library which showed the attachment name as "PDF". If I expand an item to show the attachment, it says "PDF", and then when I do right click >> Show File, the actual file name of .pdf is correct and does NOT just say "PDF.pdf". I did a test migration with debugging mode on. I submitted the report, then forced closed Zotero since there is no way to interrupt the migration.
Report ID: D1210642334
Screenshot of issue: https://i.imgur.com/prCDzQo.png
We do have further speed improvements planned, though. Among other things, part of the import time is also taking up by full-text indexing, which currently happens during import. The benefit of that is that a full-text search works immediately if someone tries it, but it might be better to perform indexing in the background after the import so that the imported items are available more quickly. That's not actually a bug — the bug is really that some attachments are named after the filename. The attachment title is meant to be separate, and when there's a single PDF, there's not much value in showing the filename, which is usually based on the metadata that's already available in the parent item row. Instead, we just set it to the less-distracting "PDF". But right now that title isn't being properly passed through to all attachments and they're just ending up named after the filename.
For non-PDF files and cases where there are multiple files attached to an item, using the filename is appropriate.
Personally I don't really care about the slow import since it's a one time migration process. I just though I let you guys know about this.
Once again, thank you very much for this new feature!!!