Re: [Bibdesk-users] votes on 1.3.13

[Christiaan H. <cmh...@gm...>]

On 30 Dec 2007, at 11:14 PM, Simon Spiegel wrote:

>
> On 30.12.2007, at 22:59, Christiaan Hofman wrote:
>
>>
>> On 30 Dec 2007, at 10:44 PM, Simon Spiegel wrote:
>>
>>>
>>> On 30.12.2007, at 21:33, Christiaan Hofman wrote:
>>>
>>>>
>>>> On 30 Dec 2007, at 9:21 PM, Simon Spiegel wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> That shouldn't happen. Does it remain a question mark when you
>>>> reopen
>>>> the detail editor, and in the main window?
>>>
>>> Yes. It also happens with a completely new .bib file.
>>>
>>>>> I don't see this, for me this works exactly as expected. What are
>>>>> your auto-file preferences? And what is the old/new path for the
>>>>> file?
>>>
>>> - File papers in fixed location /Volumes/Daten/Filmwissenschaft/ 
>>> Diss/
>>> Publikationen
>>> - File papers automatically
>>> - Warn before moving a folder
>>> - Local File Format Costum: %a1/%A1%Y%u0%e
>>>
>>>
>>> --
>>> Simon Spiegel
>>
>> Oh, you're having your files on a separate disk? That's bad, as
>> aliases don't work over volumes. I'm not sure how we could solve  
>> this.
>
> Ah, I wasn't aware that this is a problem. I used to have this ever
> since autofile option became available. It's not that this is a huge
> problem for me, I could move the files to my main volume, but BibDesk
> should at least warn the user that this doesn't work.
>
> Thinking about it, what exactly is the problem here? As I said: The
> file gets moved properly, it just isn't displayed properly. But if I
> then drag the moved file inside BibDesk, it is again properly
> displayed. So this does work somehow. Maybe this extra step has just
> to be added when the location is on another disk ...
>
> simon
>
> --
> Simon Spiegel

We save the file using an alias with relative path information.  
However during a bibdesk run we also keep another type of reference  
as the main link to the file (however this type of reference cannot  
be saved). Relative aliases require the two paths involved to be on  
the same volume, so that 's where it probably goes wrong. However  
it's still possible to link files across volumes, because we actually  
work with the other type of reference. But tracking it when it moves  
can get broken. I'm not sure where precisely things go wrong and how  
to catch problems. But it sure should get fixed somehow.

Christiaan