That does not address the issues discussed here in any way. The problem is not that the paths are different. The OP had that covered, as he was even using the exact same paths on both systems (not even through symlinks). It’s not the path where the system specific information comes in. The file system specific information is not in the path, it’s in the alias data that BibDesk saved in the Bdsk-File-* fields. And the point is that this means that these fields change whenever you save from a different file system from the previous time.
Christiaan > On Nov 19, 2015, at 13:09, Fischlin Andreas <[email protected]> > wrote: > > I have avoided parts of the issue first described in this discussion by > introducing symbolic links mirroring any system involved. The situation is, > however, slightly different in that I sync or transfer also the BibDesk file > among systems first. When I then open the bib-file with BibDesk on any of the > involved systems, the symbolic links ensure that the identical path exists as > well. E.g. two systems with two users ‘userx’ and ‘usery’ having both a > different location where the pdf repository resides: > > /Users/userx/Documents/DataBases/PDFsOfRefs > /Users/usery/MyProject/Literature/BibDesk/pdfRepository > > and having on each of those systems symbolic links such that on both systems > exist both paths. This trick avoids losing the linked files and BibDesk does > since years honor such a change of systems without a glitch. No need to go > for local file field and the 1 to n relationship can be maintained the usual > very powerful and convenient manner as BD offers. > > Regards, > Andreas > > > ETH Zurich > Prof. em. Dr. Andreas Fischlin > Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics > CHN E 21.1 > Universitaetstrasse 16 > 8092 Zurich > SWITZERLAND > > [email protected] <mailto:[email protected]> > www.sysecol.ethz.ch <http://www.sysecol.ethz.ch/> > > +41 44 633-6090 phone > +41 44 633-1136 fax > +41 79 595-4050 mobile > > Make it as simple as possible, but distrust it! > ________________________________________________________________________ > > > > > > On 19 Nov 2015, at 11:44, Christiaan Hofman <[email protected] > <mailto:[email protected]>> wrote: > >>> >>> On Nov 13, 2015, at 23:23, Christiaan Hofman <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On Nov 13, 2015, at 20:52, Adam R. Maxwell <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Nov 13, 2015, at 04:05 , macula <[email protected] <mailto:[email protected]>> >>>>> wrote: >>>>> >>>>> Regarding the huge diffs, I am fully in agreement with Michael. Autofile >>>>> is a great feature, and so is the preview side panel, and it would be a >>>>> pity to view this as an either/or proposition. >>>> >>>> The underlying code for files is pretty complicated, and some if it >>>> has been there since the editor window had a drawer where you could >>>> view a single attached PDF :). >>>> >>>> The fileview and alias code was a massive rewrite, and it's just >>>> not really compatible with the older attachment code. Maybe it could >>>> be changed at the serialization level to only save a path, but reading >>>> it would then be tricky… >>>> >>>>> I just feel that the new >>>>> BibDesk is somehow rubbing against the aesthetic and openness of the >>>>> Bib(La)TeX format. >>>> >>>> I disagree with this; we namespace our private fields with a bdsk- >>>> prefix, to avoid clobbering anyone else's data. By comparison, >>>> I think BibLaTeX is not compatible with BibTeX as it's been defined >>>> for years (notably having changed the semantics of a field or two). >>>> This makes it impossible for BibDesk to support both. >>>> >>>> BibDesk's Date-Modified, Date-Added, Annote, Abstract are exceptions >>>> that predate our notion of private fields. >>>> >>>>> Many if not all of us are scholars and share our >>>>> materials with students and colleagues. Part of the appeal of this >>>>> format is that its plain-text elegance and standardization liberate the >>>>> data from any particular software. The very fact that BibDesk now >>>>> presumes to "own" the database is a bit contrary to the philosophy of >>>>> BibTeX, I think. >>>> >>>> To be clear, we "own" the bdsk-fields, and other well-behaved software >>>> should just ignore those. Sharing a .bib and set of attached files on >>>> a fileserver or cloud is an extremely complicated case, especially when >>>> multiple users can access it. Apple screws it up regularly, so I just >>>> prefer not to even try :). >>>> >>>>> More practically, wouldn't this issue be solved if there was a scheme >>>>> for storing the links locally in a separate file? I am thinking of a >>>>> simple one-to-one index assigning each bibliographic entry (identified >>>>> either by its BibTeX key or by a BibDesk-generate UUID) to a list of >>>>> links to the entry's attachments? >>>> >>>> Two separate files would be a disaster with Finder copies and >>>> moving/renaming/sharing. I suppose one could store it in the resource >>>> fork or extended attributes, but that's a different ball of hurt. >>>> >>>> We considered doing this in a number of ways (a new data file format, >>>> a package-based format). The former died on the vine, and the >>>> latter makes it hard to get to the .bib file for TeX usage, and isn't >>>> really compatible with version control systems. >>>> >>>>> For the time being, Michael, I am thinking to move my BibDesk-owned bib >>>>> file out of the git repo and into dropbox, then use bibtool to produce a >>>>> git-friendly version stripped of all links. >>>> >>>> You can probably do this with a template also, or use the minimal >>>> BibTeX export (but that might remove too much). >>>> >>>> I'm not entirely unsympathetic to the problems here, but they're not >>>> trivial to solve in a way that is robust, user-friendly, and backwards >>>> compatible. >>>> >>>> Adam >>>> >>> >>> >>> Optionally leaving out the alias data would lead to somewhat fragile data, >>> so the link could easily be lost. And it would make it very hard to move >>> the database in your file system. It would certainly lead to data that is >>> not backwards compatible, because currently the link is simply discarded >>> when the alias data is missing. Also, using a full path instead of the >>> alias would generally not solve anything because in general the directory >>> structure on different file system will not match, so such a partial >>> solution would be greatly reduced in value. So though I am also sympathetic >>> to the problem, I am very much ambivalent to whether we should really try >>> to solve this. >>> >>> Christiaan >> >> >> To test some of this out I have added a hidden (boolean) preference in the >> latest nightly build to only save the relative path of the linked files. >> It’s a boolean pref with key BDSKSaveLinkedFilesAsRelativePathOnly (see the >> Wiki on how to set this). Be careful though. The data will be much more >> fragile, and the saved data will not be compatible with older versions of >> BibDesk (i.e. before 1.6.4 (3701)). (When you’d open a file saved with this >> option in an older version of BD the linked files will be gone). >> >> For now this is just for testing purposes. I am not sure what to do with >> this, whether to advertise this on the Wiki, integrate this as an actual >> pref (that could be dangerous), or remove it later. >> >> Christiaan
------------------------------------------------------------------------------
_______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
