Relative path names after migrating Cloud service

AndySymons

For some years now I have kept my library of linked attachments on iCloud. I use Zotero on several computers, MacOS and recently Windows too.

Just migrated my cloud service from iCloud to Dropbox (because iCloud does not work with windows). I assumed all I had to do was change the base pathname in the advanced settings and all links in Zotero would point towards the new location.
However, if I try to open a linked attachment, it says it can't find it and gives the old pathname.

The old iCloud base directory pathname was:
/Users/myname/Library/Mobile Documents/com~apple~CloudDocs/Application Data/Zotero

then a subfolder /Linked attachments/, which I think is not part of the 'base directory'.


The new Dropbox base pathname is:
/Users/myname/Dropbox/Application Data/Zotero

What am I doing wrong?

BTW, Zotfile is set with the custom location as
/Users/myname/Dropbox/Application Data/Zotero/Linked Attachments

report ID 1085933519

dstillman

If it's showing the old path and the base directory isn't still set to that path on this computer, then 1) the base directory wasn't set properly before, 2) you haven't synced either the computer where it was set or this computer, or 3) the files didn't exist within the new base directory when you changed the setting. Whichever it is, you still have absolute paths on this computer for those files.

You'll need to set the base directory to the old location to convert them to relative paths and then switch back to the new location. If the files exist at the correct relative paths in the new location, they'll remain as relative paths and will open properly. If the files don't exist, they'll be converted back to absolute paths within the old location and you'll get the not-found error when you try to open them.

AndySymons

I'm not sure either which of 1 or 2 it was. It was not 3 because the files were there but were not being found by Zotero.

1) It would be possible to put the files back where they were, temporarily, though a bit of trouble because I will have to recreate the iCloud directory and MacOS has a strange way of naming iCloud paths. Still easier than changing 3,204 links by hand, though!

2) Should I do that before or after I 'revert to absolute paths' in Zotero preferences? If I do it before, will it then try to change the existing names somehow?

3) Once I am back to where I was before, do I then change the Base Directory to the new location /Users/myname/Dropbox/Application data/Zotero? Do I understand correctly that it will always add /Linked Attachments/ to this path?

4) Will it then move the files as well, or do I need copies in both places during transition?

Sorry to bang on, but I remember having problems before where I ended up with /Linked attachments/Linked attachments, and it seems that Zotfile is different in that it requires /Linked attachments/ as part of the path?

None of this is difficult once it is clear, but it takes a lot of time to clean up if I make a mistake, so feel free to explain it as if to a 3-year-old :-)

AndySymons

p.s.
5) Is there an easy way of seeing what path a given Zotero item is actually using? And whether that is absolute or relative? I can of course use 'show file' to see where it is on the disk if the link is good, and if I change the file name by hand to break the link, then it tells me the path where it is looking in the error message. However, in neither case can I see whether this is an absolute path or constructed from a base plus /Linked attachments/.

dstillman

You don't need to put the files back where they are — I didn't say to do that and it's not required. You just need the same folder to exist with the same path so that you can set it temporarily as the base directory. That will essentially collect any files under that path and store them with appropriate relative paths. As long as they then exist at the same relative path when you switch back to the new base directory, they'll remain as relative. If they don't exist at the same relative path in the new base directory, they'll be reverted to absolute.

dstillman

Is there an easy way of seeing what path a given Zotero item is actually using?

It's clear from what happens.

- If you have a base directory set and the file is within it and Zotero the file is accessible from Zotero (filled blue dot or you can open the file), then you know it's set properly using a relative path.

- If you have a base directory set and the file is within it and isn't accessible in Zotero, the relative path is wrong, and it will tell you where it's looking. This would only happen if you set the base directory differently at different times (e.g., to "Linked attachments" at one point and the parent directory of that at another point) or you moved the files within the base directory outside of Zotero.

- If you have a base directory set and the file isn't within it and isn't accessible in Zotero, it will tell you the path in the error message, and it's by definition stored as an absolute path, because there's no way it could've been constructed from your base directory.

dstillman

(This sounds complicated but it really does just work as long as you always set the base directory to the same location relative to the files on all computers and keep those computers in sync. It only gets a little messy if you set the base directory incorrectly (including changing the base directory before moving the files, such that the files don't yet exist under that folder, which causes them to be reverted to absolute paths so that they continue to work).)

lampuiho

The only way I have found is using a SQLite browser and change them all back to relative path after installing zotero and setting base path on a new computer.

adamsmith

You really want to stay away from touching the SQLite -- it's too easy to break something in ways that's not immediately obviously and very difficult to fix.
You can use the Zutilo add-on to both look at current paths and to bulk change existing ones (Zutilo does so using the local API, so safely in that sense, but when using the bulk functionality it's still easy to break things, albeit in a more immediately obvious way, so a good back-up of the database is essential).