Sharing DB between Mac OS X and WinXP

Frit

Hi Folks,

Happy New Year.

FF 3.0.5; Z1.09; WinXP(virtual); MacOSX 10.5.6

I recently purchased a Macbook Pro and am shifting from Wintel to Mac. All of my files and s/w, however, are Windows. So, I'm using virtualization s/w (Fusion) to run both OSs on the Mac. I'm trying to share the Zotero DB between the platforms but there are some glitches. Even if it is unreasonable to share on an ongoing basis, this is a glitch, I think, in migrating to MacOS.

When a pdf is saved to the DB, is the choice of 'blank space' replacement with a char str made by the browser or Zotero? Using, on the web page:

http://www.cec.org/pubs_docs/documents/index.cfm?varlan=english&ID=2022

is a link to a pdf doc entitled:

"Renewable Energy Financing Case Studies"

If I hover on the link, the file name in the link as displayed in the FF status bar has spaces in it. If, in FF 3.0.5 on either WinXP (virtualized) or Mac OS X, I 'copy link location' and paste into a word processor, the blanks are replaced by "%20".

If I save to Zotero the pdf displayed 'in browser", the pdf file is saved differently on XP from MacOSX. Z-XP saves as:

RE%20Financing%20Case%20Studies_en

Z-OS X saves as:

RE20Financing20Case20Studies_en.

There are other strange things that I need to resolve when I sync files from an NTFS virtual disk to a shared (between OSs, faciliated by the virtualization s/w) HFS+ disk but I thought this is a good place to start.

Any comments? Should I expect a Z DB created to WinXP to be note-for-note compatible with a Z DB created in Mac OSX?

Thanks!

Ken

ahoward

You might have more luck using Zotero 1.5 Sync Preview and syncing your library/files, rather than sharing a networked library over virtualization software. Obviously, back everything up first, but it should work nicely. Unless there's some nuance I'm missing that makes it necessary to stick with the networked library.

Frit

Thanks, that might be a good option for the future once the feature has been released.

Still looking for answers to questions.

Frit

Update:

If, in WinXP, I try to copy RE%20Financing%20Case%20Studies_en from virtual NTFS disk to the physical HFS+ disk, I get an error dialogue "Cannot copy [filename]: The filename, directory name, or volume name syntax is incorrect."

Now, I tried copying the folder for the Zotero record (within storage folder) from virtual NTFS drive to a FAT32 USB drive in XP (virtual) and then from the flash USB drive to the HFS+ drive in OSX. This worked fine and the name was identical on both XP and HFS+ drives. (both had '%20' as space replacement).

Leads me to look at two things:

1. there is a problem with the virualization s/w in copying files with certain unusual characters from ntfs virtual to shared hfs+ drive -- this I will investigate with VMware, and

2. there is the issue of why Z names a saved pdf differently when saving in XP vs. OSX -- i.e. '%20' vs '20' for blank character replacement.

Obviously there are a few things from disparate s/w interacting here but it would be nice to get to the bottom of it.

Frit

Hey folks,

Could a Z person answer the last question in the first post on this thread?

Thank you!

Ken

ahoward

Sorry, I'd have replied if I had anything intelligent to contribute. I'll try to bring your question to the attention of someone better able to help you out.

Frit

Thanks very much. Now that I am working virtually x-platform, I'm just trying to get to know if there are differences that I, as a user, need to know in the way the files are handled.

Frit

Hmmmm... must have you guys stumped.

Remembering the discusion I had with Dan some time ago re what is and what isn't a DB, let me clarify my question.

Should I expect the artifacts saved from a given webpage to be identical between Z-Win and Z-Mac; i.e. the Zotero storage files could be opened in Z-Win and Z-Mac without any issues arising?

A further thought re pdfs that Z saves. Is the name mangling done by Z or by the platform? (i.e. Win - space char replced with ''%20'; Mac - space char replaced with '20').

Thanks as always.

Ken