> I don't quite understand how the links are broken, and what distinguishes
> a broken link from a working one.
I don't know how they get broken either but an OF Ninja confirmed the problem... What distinguishes it is that a working one, when I click on it, opens the file (for me, usually a PDF file living in my Dropbox folder and opening in Adobe Acrobat when I click on the attachment). A broken link works in one of 2 ways: either it says "original cannot be found" and asks me to locate it, or it says the same thing but then the file selection menu that comes up actually has the right folder opened and the right file highlighted (although I still have to click on it before it will open). So I think there are 2 levels of broken links somehow.
> OF stores an attachment link as a "file://path" URL, and it sounds from
> your other posts like the file is still there, but when OF hands off the URL
> to be opened, an error occurs. Complicating matters a bit for the
> would-be script author is that there doesn't appear to be any way to see
> which notes have attachments, much less get at them, except by looking
> directly at the database files. Assuming you can generate that list,
I can - an OF Ninja actually sent me a 1-line zsh code that scans the database and generates a list of all links. I guess I could just use zsh to test for the presence of each one. But they are all there, so it wouldn't help - what I need is a script from within OF to tell me which files it won't be able to open even though the path is right and the file exists...
> and test them all to see if they can be opened, what happens when you
> find one that fails?
I'll go and re-link it by hand, so that I don't get the nasty surprise of not being able to open it when I really need it (on the road).
> To me, this smells like a problem with Launch Services. You might try
> rebuilding the Launch Services database as described > here
> the next time you see this (or now, and see if you ever see it again).
ok I'll try (I will see it again - it's perfectly reproducible).
thanks
Mike
> a broken link from a working one.
I don't know how they get broken either but an OF Ninja confirmed the problem... What distinguishes it is that a working one, when I click on it, opens the file (for me, usually a PDF file living in my Dropbox folder and opening in Adobe Acrobat when I click on the attachment). A broken link works in one of 2 ways: either it says "original cannot be found" and asks me to locate it, or it says the same thing but then the file selection menu that comes up actually has the right folder opened and the right file highlighted (although I still have to click on it before it will open). So I think there are 2 levels of broken links somehow.
> OF stores an attachment link as a "file://path" URL, and it sounds from
> your other posts like the file is still there, but when OF hands off the URL
> to be opened, an error occurs. Complicating matters a bit for the
> would-be script author is that there doesn't appear to be any way to see
> which notes have attachments, much less get at them, except by looking
> directly at the database files. Assuming you can generate that list,
I can - an OF Ninja actually sent me a 1-line zsh code that scans the database and generates a list of all links. I guess I could just use zsh to test for the presence of each one. But they are all there, so it wouldn't help - what I need is a script from within OF to tell me which files it won't be able to open even though the path is right and the file exists...
> and test them all to see if they can be opened, what happens when you
> find one that fails?
I'll go and re-link it by hand, so that I don't get the nasty surprise of not being able to open it when I really need it (on the road).
> To me, this smells like a problem with Launch Services. You might try
> rebuilding the Launch Services database as described > here
> the next time you see this (or now, and see if you ever see it again).
ok I'll try (I will see it again - it's perfectly reproducible).
thanks
Mike
Threaded Mode