Hi,
Is there a way to retrieve the record link or its recordGUID for a record I’m creating through AppleScript?
I thought the what I’m looking for is (id of library record) but it seems like that is actually another internal value. What I need is obtaining something like:
x-eaglefiler://open?library=ka.eflibrary&recordGUID=faXufISIT4qhsiuFCaEvVw
or at least the recordGUID to construct the above myself.
tia,
A://
After you create the record, just get its “URL” property. This will give you the x-eaglefiler URL with the recordGUID.
The “id” property can also be used to identify records in a script. It’s more efficient than using GUIDs. However, if you will be persisting the URL or identifier, you should use the GUID because it will stay the same if the library’s database is rebuilt.
Fantastic! Importing URLs, I confess that was the last property I was planning to try :-).
Is there any way to tell EagleFiler to select the newly created record through AppleScript?
So far the only idea I have is to do a
do shell script "open -a EagleFiler URL"
but I’m wondering if there’s a better way.
You can set the “selected records” property of the “browser window”. However, this currently requires that the source list has something selected that would contain the record. This is because the selection of the source list is not currently scriptable, although you could use GUI scripting to drive the “Go” menu.
Can anyone clarify the GUID?
I think this is what I want, but I can’t quite figure it out. I’m looking for an immutable link to a record (i.e. a file). Right now, when I use “Copy Record Link” to link from another document I’m writing back to an EF file, it takes the entire URL. This gets disrupted if I change anything in the EF library structure, such as moving it to another drive, or moving the particular file to another folder.
Is GUID an immutable link to a particular record? If so, why do I get no result if I search EF using the GUID? Is it an Apple file system thing, and not accessible to EagleFiler?
Last, does anyone have another suggestion for creating unchanging links? I could randomly create a 10 digit number that I store in the Notes field, but that is clugey (sp?).
That’s what the record link is intended for.
It’s true that the path to the library will change if you move the library itself to a different folder or drive. However, if you have the library open, and then you click the link, EagleFiler will see that it has a library with the same name as the link, and it will look there for the record. Does that make sense?
Yes.
It might make sense to add that as a feature in the future, however right now EagleFiler only indexes the record’s contents and visible metadata for searching. How would searching by GUID be better for you than just clicking the link?
No, the GUID is an EagleFiler thing. It’s only stored in EagleFiler’s database, not in the file itself.
What are you trying to accomplish that isn’t currently possible?
Update: unique ID for files
Well, I’ve outsmarted myself. I changed the name and directory of a database.
As a result, none of the existing links to documents will work automatically. However, by manually substituting the correct directory, I should be able to recover any files that I did not move within EF.
I also split the DB, putting half into a new one (which will eventually go on Dropbox). I expect in the new DB, all the docs will get a new GUID. In that case, even a searchable GUID would not have worked.
So, this is a scenario in which some kind of unique ID for a file would be useful. One method would be to create my own, and simply put it in the file as a text comment. That works fine in a text or word processing file; in a PDF could I put it into the description section of the document. I think that is also a more robust solution, because any document can be found using Spotlight.
Has anyone done something similar? Any suggestions? thanks
As long as you don’t move the file between disks, aliases do what you want — you can rename/move the file as much as you want and the alias will still resolve as you expect. (If you’re populating your database programmatically, the user-facing term “alias” has been replaced by NSURL "bookmark"s, like “clipboard” vs “pasteboard”).
I would expect the links to still work even if the records were moved within EagleFiler.
When you copy a record from one EagleFiler library to another (or if you rebuild a library) it will keep the same GUID.
It does seem to me that EagleFiler should handle this case better, though. Maybe if the library path in the link is invalid, check the other open libraries for that GUID?
Thanks for the advice. Yes, that should work if EF is interpreting the links. Although my understanding was that links (embedded in, for example, a word processing document) are handled by the OS, not EF itself. Clearly I should do some experiments if I really want to understand all this.
In any case, I’ve decided to hand-embed a random ID into each document that I link to. That way, I can always use both Spotlight and EF’s search to find the document, no matter where it wanders to.
The OS doesn’t interpret the contents of EagleFiler links. If you click a link in another app, it will just launch EagleFiler and tell it to open the link.