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 encountered 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 in terested 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 new 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 _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
