Hi all, Like Graham, I have encountered this situation quite often when leaving BibDesk open on my laptop and then highlighting a PDF on my iPad. Once I sync my PDF collection back to Dropbox so that my highlights are available on my laptop, I often lose the link to the PDF in BibDesk.
While this is not a bug (as I was informed on the Dropbox forums where I complained about this), I agree with Andreas that the optimal solution would be a change in Dropbox behavior: for example, they could have some kind of single-user/non-caching flag that you could set on a per directory basis. I'm sure this is not going to happen anytime soon (or at all), so I'm eager to try Graham's solution. Best, Jeremy On 9/3/13 6:20 PM, Graham Dennis wrote: > Hi Andreas, > > Dropbox's behaviour is a feature, not a bug. Consider the following sequence > of events: > 1. User opens file A.txt (hosted in Dropbox) on computer #1 and begins to > edit the document. > 2. The same or different user opens the same file on computer #2, edits the > file A.txt and saves the file with the modified document. > 3. Back on computer #1, the user saves their changes. > > The changes saved in steps #1 and #2 are in conflict, and it is desirable to > keep both changes to the document for the user to review and resolve later. > In this situation Dropbox achieves this by moving the file that the user was > editing on computer #1 into a private cache after the edited file from > computer #2 is downloaded onto computer #1. If the file being edited on > computer #1 is saved, dropbox is able to detect this and move the conflicting > edit back into the Dropbox folder as a conflict file which the user can > resolve later. > > Neither is this a bug in Apple's code, so if this problem is to be fixed, it > must be fixed in BibDesk or with a solution like BibDeskWrapper. > >> Secondly, I'd like to remind us all that file linking/tracing as done by >> BibDesk is rather sophisticated and handles everything very well, including >> symbolic links and ordinary Finder aliases. It would be a pity, if any >> solution good for Dropbox would impact on any of these complex functions now >> very reliably handled by BibDesk. And I fear that may be the case. I am of >> course not sure whether that might be really the case or not, but fear there >> is a real risk. I do sync my bibliography files and pdf's among various Macs >> and iOS devices very well and encounter no problems nor glitches. I make >> sure on Macs that the file hierarchy is the same on all Macs (if necessary >> complemented with symbolic links) and use cloud services when syncing with >> iOS devices (my iPad, iPhone). I have never encou > ntered any difficulties in my workflow and I am happy with the reliability > by which BibDesk is handling all this. Of course, I need my own scripts to > accomplish this all conveniently. BTW, anyone interested can find all my > scripts also on my home page (http://www.sysecol.ethz.ch/people/afischli > link Software). All works very well right now, yet is sophisticated with > syncing back pdf's via symbolic links or Finder aliases via modification date > etc. I would hate if any of this would get disrupted. >> >> Sorry, for these words of caution, but I wish us all to consider all aspects >> before asking perhaps rashly for changes of BibDesk. > > I agree that caution is sensible. The way BibDeskWrapper works means that it > will always be able to resolve a file when BibDesk can. All that > BibDeskWrapper changes is which file is chosen when there are multiple > candidates. If you rename a file A.txt (with contents A) to B.txt (still > with contents A) and then create a new file A.txt with contents C, then both > files are candidates to be resolved by BibDesk by a link to "A.txt". The > current behaviour of BibDesk is that 'B.txt' (with contents A) will be > resolved if BibDesk was open while you made the changes, but 'A.txt' (with > contents C) will be resolved if BibDesk were not open. BibDeskWrapper > changes this behaviour so that 'A.txt' (with contents C) is the resolved file > in both cases. Of course if A.txt was renamed to B.txt and no ne > w file A.txt was created, then both BibDesk and BibDeskWrapper would > resolve to B.txt > > Regardless, my intention with BibDeskWrapper is to demonstrate (or find > otherwise) whether my approach is safe. As I said, I agree that caution is > sensible, so testing of the suggested behaviour is a good idea before > implementing those changes in BibDesk. > > Best Regards, > Graham Dennis > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
