Zotfile vs Zotero renaming

A quick question:
What's best practice for the renaming of pdfs? I realise I have been using Zotfile with defaults (underscores etc).
  • There are no best practices -- anything that's relatively consistent, doesn't produce overly long filenames, and works for you is fine.
  • Reason I asked is that I have been using Zotfile and only recently noticed the inbuilt Zotero renaming. I think Zotfile makes a new copy of the pdf when renaming - is that right?
  • As long as you keep files as Zotero attachments, Zotfile's and Zotero's renaming options are functionally completely equivalent, with slightly different defaults and, of course, Zotfile being much more flexible in terms of renaming patterns. Independent of renaming, when you attach a file to Zotero from your harddisk, by default that's saved as a copy.

    ZotFile offers the additional option of moving & linking files (which has significant implications), but that's entirely separate and doesn't sound like it's what you're talking about.
  • Yes, I think I was confusing those things. I'm not linking but storing all pdfs locally in the Zotero storage folder. So once they are imported into Zotero (ie saved as a copy), further renaming is done in place, right?
  • that's right, yes. And same with Zotero's own & Zotfile's rename.
  • Thanks for the confirmation.
  • edited 13 days ago
    For what it's worth:

    For the PDF (and other types of files, too) filenames I use the BibTeX citekey generated in BetterBibTeX by the pattern:

    [authors1+.:replace=.etal,+:lower][shortyear][title:skipwords:lower:abbr]

    and strip off the letters that are from the subtitle (ie only use the 'main' words from the title, not 'an', 'the' etc). (With thanks to @emilianoheyns for the tweaking of the pattern.)

    This goes back to the days when I had one folder holding the PDFs that was looked at by both ProCite and EndNote - I wanted to ensure that the PDFs were not "lost" inside the file structure of either, but visible in a separate one to both. This was also done so I could do backups of the /References folder separately from the databases themselves. It also meant that migrating to Zotero was much easier, since it was the file links that were copied across -- the folder stayed the same, and the files stayed in place.

    This way, I always know which PDF (or other type of file, such as .odt, or .gif, etc) belongs to which reference. Doing it this way also speeds up the download, rename, move and link process, since the citekey is in memory and can be used to both rename the downloaded file, and to link the file once moved into the /References folder. There are a couple more tricks, but that's the gist.

    It is very handy to always know which ref a stray file belongs to, or what a file needs to be called to belong to a ref.
  • @jvoros How can I do that? I only see the Renaming option until Zotfile options, and your pattern won't work there. I don't see an option in BetterBibTeX to rename files.

    Thanks
  • BBT doesn't do file renames -- Zotfile does file renames, but it can be configured to use the BBT-generated citation key in the rename.
  • That's right. It needs to be done manually or with Zotfile - BBT simply generates the unique identifier which then becomes the base filename for electronic files; the uniqueness is important to prevent name collisions and possible file overwrites.

    For me, these are mostly .pdf, but there are also .doc, .ppt, gif, .jpg, .tiff, .mp3 etc files with the Citekey base name. I also distinguish between final published vs (p)reprints with a "-R" added to the base before the filename extension. BBT can't do that level of file-name patterns (yet), but it gets you 95% of the way, 95% of the time, which is pretty good - especially for a complex file naming schema like I have (an artefact of LaTeX/BibTeXing way back in the day).

    I already have thousands of files named this way, since this is how I started doing it 20-odd years ago with ProCite. Each new addition gets the BBT-citekey treatment (much faster than manually). Thankfully, I haven't had to confront renaming thousands of files - but cleaning up Zotero from an EndNote import is not a simple or quick job, so I have not gotten away scot-free...
  • OK, had to search through some documentation to find out how to do that. Thanks. This also helps with syncing attachments to the iOS app, which seems to be limited by filename length. Shorter filenames sync, longer filenames don't. This is a good solution to get those attachments to sync.
  • That's right. It needs to be done manually or with Zotfile - BBT simply generates the unique identifier which then becomes the base filename for electronic files; the uniqueness is important to prevent name collisions and possible file overwrites.
    each attachment lives in its own unique folder in Zotero storage, no? Or do you mean for linked files? Does zotfile do collision protection there? BBT will generate unique citation keys if you let it, but if you pin two keys to the same citekey it won't stop you. Also goes for two pdfs under a single item.
  • I meant that the generation of BBT keys does not (seem to) produce an identifier (basename) that collides with an existing reference,* which is important since I copy the downloaded files into a single /References directory (as noted above) for historial (but also backup) reasons.

    * With regard to the citekeys - when entering new items, I sort the main database view on citekey (the vast majority of which are pinned), so I always do a quick side-of-the-eye check for a name collision. After 20-odd years this is a (useful) habit (for a number of reasons).
  • BBT on its default settings will assure that your citekeys remain unique within one library/group, but there's two ways you can make non-unique keys:

    • you pin two or more keys to the same value, or
    • you set conflict resolution to "kept", in which case if you pin a citekey to the value of another existing dynamically-generated citekey, the existing dynamic key is kept
    but other than that, if two attachments live under one zotero item, those will of course share the same key when used in renames.
  • I pin the keys once I am happy with them being unique (the vast majority arrived already pinned from the EndNote import process which required a rename of the EndNote "Label" to "Citekey: `label`" into Extra in the import file - help on this in these Forums a couple of years ago made this time-saver possible).

    I also tell BBT to keep them unique across all libraries and to postfix non-pinned keys if there is a conflict. The collision-scan will reveal if this is the case, in which case I modify the key to something unique and then pin it. (There are only ever very few unpinned keys at any one time, and these are automagically made unique by postfixing in the time before they get changed and pinned.) Again, a procedure born from the policy of storing all refs in a single folder.

    Mileage may vary for other use-cases. But this way, I know I can do a quick search in the Refs folder to see if I have something by someone, independently of having to fire up any particular bib software to search through. Same basic idea as using Markdown for note-taking (eg Zettlr) - trying to keep things as specific software-independent as possible.
Sign In or Register to comment.