Christiaan Hofman wrote:
Useful info. However, please note, I can't have the same absolute file path on my two systems, since MacBook Air volume partitioning is too risky in terms of wasting disk space in a tight disk situation and all my traditional volume partitioning on large hard disks can't be easily changed to accomodate just that. Then and I do not see how I can have my many bib files in various project folders and using only a relative path to the pdf repository folder. For all these reasons I can't use relative paths and have to go for the sym link solution. Moreover, this helps not only BibDesk, but also EndNote, and my FileMaker central data base. Each being able to support access to the same linked files.On Sep 18, 2009, at 21:47, Maxwell, Adam R wrote:On 09/18/09 10:49, "Andreas Fischlin" <[email protected]> wrote:3) The only difficulty I have not been able to overcome in an elegant manners is the attempt by BibDesk on my MacBook Air to access the other big machine during launch. When I am not connected to the internet -, as soon as I launch a newly transferred .bib file, my Air makes attempts to access my other Mac.I guess that could happen, but I'm a bit surprised. Do you have anyafp/smb/nfs links? Maybe resolving the fileID first triggers this behavior;I don't recall how that's done.IIRC, BD searches in this order: relative path, file ID, absolute path. This means that if you maintain the same relative path from your .bib file and your papers on both systems you won't get this problem (or any of the other problems). This is really what you should always do when you synchronize your database between different systems. Apart from that I am not 100% when attempts will be made to mount volumes, because Apple does not tell us how they resolve aliases.
Yes I do have afp links present, but they do not matter. I just made a test. Moreover, note that the auto mounting happens not for the afp server that I reference in these afp URLs, it is the disk volume where my pdf repository resides on my main Mac and therefore I surmise it must be the file URLs that may continue to point to that volume or some other disk reference in the bib file? As Christiaan stated: relative path, fails after sync, file ids, point to the other disk and could cause the auto mount, absolute path do succeed.
I have now also figured out what caused the automount. Having a Finder alias, not sym link in the pdf repository folder that gets synced, yet references a not synced pdf, since it resides outside the pdf repository folder, causes the automounting. So this is actually merely a problem of my particular bib file not properly constraining synced aliases only to originals that are not also synced. The only annoying thing is, if I happen to select a record with such a broken Finder alias, it is no longer possible to open the bib-file, since BibDesk gives not up trying to access the disk no longer available. I have to force quit BibDesk or mount the disk to open the bib file again (or edit away the selection as . Anyway your suggestions helped and made me understand the problem having nothing to do with BibDesk.
Finally, some file URLs getting broken. Normally, i.e. I have the path emulation of each partner Mac working fine, this does not occur. Nevertheless I have now encountered it with some bib files for reasons which escape me and I can't reconstruct it. Since it happened once with a rather large bib file I could not resync I wrote the fixing AppleScript. However, I would be glad if someone could tell me whether there is a technique to extract from Bdsk-File-1{} entries that are broken in such a manner the actual info, i.e. relative or absolute path. Since my attempts to use AppleScript statements such as
set allLinkedFiles to (get POSIX path of linked files) set allLinkedHFSFiles to (get linked files) set allLinkedFileURLs to (get URL of linked files)resulted in that situation only as a missing value item, yet the bib file itself still contained the Bdsk-File-1{....} fields with lots of for human eyes unreadable content.
Andreas
Christiaan ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart yourdeveloping skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now!http://p.sf.net/sfu/devconf _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
-- ________________________________________________________________________ ETH Zurich Prof. Dr. Andreas Fischlin Systems Ecology - Institute of Integrative Biology CHN E 21.1 Universitaetstrasse 16 8092 Zurich SWITZERLAND [email protected] www.sysecol.ethz.ch/staff/af +41 44 633-6090 phone +41 44 633-1136 fax Make it as simple as possible, but distrust it! ________________________________________________________________________ * *
<<attachment: andreas_fischlin.vcf>>
------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf
_______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
