This is the nub of the problem, and I’m just not seeing that here.
If I understand correctly, you are putting your Script Libraries folder in the Dropbox folder, and the symlink in ~/Libraries. And from what I’ve read, it has to be done this way around – if you put the symlink in the dropbox folder, Dropbox doesn’t know when things change, and doesn’t propagate any changes.
That suggests that symlinks pose a challenge to Dropbox – and frameworks are built around symlinks.
Your earlier screenshot also shows a framework size bigger than any I’ve released, so something has gone astray at some stage. And it’s only you and Dropbox that read and write into that folder, AFAIK.
So I can’t actually point my finger at Dropbox for this – but I can’t see anything else to suggest (unless it’s a 10.11 thing).
It’s partly a support thing, really. If it’s editable and someone says they’re having a problem, I can’t be sure what code they’re actually running. I’ve had this sort of problem before…
That said, there’s no reason to hide the code – I can include a copy of it. It probably won’t enlighten you much about what’s happening, though, because that nearly all happens in the framework. (FMDB is open source, so you can read that code too. FMDBAS mostly just wraps that code in a more AS friendly way.)
Here it the lib code with lots of stuff snipped for brevity:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework "FMDBAS"
script forInheritance
--
end script
on scriptObjectDbInit()
script
property parent : forInheritance
property theRealSQLDb : missing value
on underlyingFMDatabase()
return theRealSQLDb
end underlyingFMDatabase
on openReadOnly()
theRealSQLDb's openWithFlagsAS:1
end openReadOnly
on openReadWrite()
theRealSQLDb's openWithFlagsAS:2
end openReadWrite
on openReadWriteCreate()
theRealSQLDb's openWithFlagsAS:6
end openReadWriteCreate
on |close|()
theRealSQLDb's closeAS()
set my theRealSQLDb to missing value -- so script doesn't need to store pointer
end |close|
on writeOpenInMemoryDbToFile:fileOrPath
theRealSQLDb's writeOpenInMemoryDatabaseToFileOrPathAS:fileOrPath
end writeOpenInMemoryDbToFile:
on beginTransaction()
theRealSQLDb's beginTransactionAS()
end beginTransaction
on commit()
theRealSQLDb's commitAS()
end commit
on rollback()
theRealSQLDb's rollbackAS()
end rollback
-- lots more similar handlers snipped
end script
end scriptObjectDbInit
on makeNewDbWith:fileOrPath
set myRealSQLDb to my scriptObjectDbInit()
set thisSQLDb to current application's FMDatabase's databaseWithFileOrPathAS:fileOrPath
set myRealSQLDb's theRealSQLDb to thisSQLDb
return myRealSQLDb
end makeNewDbWith:
on makeNewDbInMemoryAndOpenedFrom:pathOrFile
set myRealSQLDb to my scriptObjectDbInit()
set thisSQLDb to current application's FMDatabase's databaseInMemoryAndOpenedFromFileOrPathAS:pathOrFile
set myRealSQLDb's theRealSQLDb to thisSQLDb
return myRealSQLDb
end makeNewDbInMemoryAndOpenedFrom:
They’re all pretty much covered in the new Read Me file.
Shane, you could be on to something. This is very strange.
On a hunch, I copied your last zip file (SQLite Lib.scptd.zip) with just the SQLite Lib file to one of my local folders, not under the DropBox setup. I unzipped the file, and then copied the Lib file to my symlinked Script Libraries folder under the DropBox setup.
Now when I run your latest script (as above), it works fine.
So, it would seem that unzipping a file that is stored under the DropBox setup caused some problem. This is very strange, because I have unzipped many other apps under DropBox, and I’ve never had this issue. But maybe that’s because all of those apps ended up in my normal Applications folder, which is, of course, NOT symlinked.
Is there some way I can do a file compare on the two SQLite Lib.scptd files, so I can identify what changed when I unzipped it in DropBox?
If I can determine what changed, then I can file a Bug Report with DropBox.
I’m not sure a file compare is going to help much.
But the fact that you have to link the Script Libraries folder as you do in the first place suggests to me it’s unlikely Dropbox can do anything about the issue.
If I had to guess, I’d do a bit of hand waving and say that Dropbox is getting confused trying to sync both the symlinks and the folders they’re pointing to and getting them out of sync somehow.
I don’t know what you mean by “you have to link the Script Libraries folder as you do in the first place”. I’m using a symlink in the normal, typical manner.
Just to be clear, here’s my setup:
In my ~/Library folder, I have a symlink named “Script Libraries”:
The symlink points to a normal folder in my DropBox Setup, named “Script Libraries”:
/Users/Shared/Dropbox/SW/DEV/LINKED_FOLDERS/Script Libraries
###The “Script Libraries” Symlink
IAC, I’ve done enough tests now to convince myself that the issue is caused by a framework being in the script lib package, when the package is in a folder synced by Dropbox.
This fails consistently: using the SQLite Lib.scptd when that package is in a folder synced by Dropbox
Each of These Work consistently:
Pause the DropBox sync service, and use SQLite Lib.scptd in the symlinked folder.
Put the SQLite Lib.scptd in the normal non-symlinked, ~/Library/Script Libraries folder
Remove the FMDBAS.framework package from SQLite Lib.scptd, and put it in ~/Library/Frameworks, but keep SQLite Lib.scptd in the symlinked Dropbox folder
I don’t understand this. The ONLY folder DropBox is syncing is the “Script Libraries” folder here:
/Users/Shared/Dropbox/SW/DEV/LINKED_FOLDERS/Script Libraries
It is NOT syncing the symlink to this folder.
This is the ONLY issue I have had with DropBox over the many years I’ve been using it. I have a whole set of folders in the DropBox sync path that I have either symlinks or aliases (all outside of the sync path) that point to these folders. Until now, this has allowed me to keep all of my Macs in sync with virtually no effort or issues.
Thanks for your help in trying to resolve this issue.
I mean that Dropbox must have the “real” folder rather than the symlink – you can’t do it the other way around and put a symlink to your Script Libraries folder in the Dropbox folder. If symlinks caused no issues for Dropbox, you would expect it to work fine either way. But it doesn’t.
Within a framework folder there are both folders and symlinks to those same folders – both are in the sync path, and I’m speculating that that is confusing Dropbox.
As I explained above, the Script Libraries folder in the DropBox path is a real folder, it is NOT a symlink. So Dropbox should not have any issues with it.
I must be missing your point, and perhaps you’re missing minel
It is a real Mac folder. It is not a symlink. DropBox knows nothing about another file, outside of the DropBox setup, that is a symlink that points to this folder.
That does not appear to be the case, based on a test I just ran.
I put a symlink in a folder inside of the DropBox setup that points to a folder outside of DropBox. When I double-click on the symlink, it opens the target folder just fine.
I’m setting up a new Mac from scratch and get the following error when trying to use a script applet that uses SQLite Lib2:
The bundle “FMDBAS.framework” couldn’t be loaded Number -4960
I installed SQLite Lib2 fresh from Shane’s library pack app which I freshly downloaded and have no other versions of the library in my Scripts Library folder.
When you get the error, go to System Preferences/Settings --> Privacy & Security, find the Security section, and there should be a button that lets you grant access to FMDBAS.framework.
I’ve been playing around with this but can’t find it. The Security section only has the choice of whether to allow apps from Appstore only or App Store and recognised devs, options for Firevolt, and the new lock down mode.
I also explored all (we… most of) the sections under Privacy including developer tools, automation, accessibility, full disk access, etc, but it didn’t appear there either.
Under dev tools in privacy there is an option for Terminal, which I enabled just to test, but it had no affect.
I tried running the applet from SD, from the applet directly, and while the applet/script was still running. Couldn’t find anything.
What would I need to do to remove the quarantine info? Is there another way to open the framework (e.g. in Terminal or something) such that Gatekeeper will prompt me to allow it?
PS The framework seems to work fine in run-only applets that are already code signed and notarised etc. It’s just the dev versions being used from ScriptDebugger that seem to be having an issue. I’m getting the equivalent error with the framework used by MyriadTablesLIb as well (unsurprisingly). None of this is surprising given it’s a quarantine issue but just thought I’d add it for clarification.
To be honest, I can’t help much. The Gatekeeper prompt normally resulted in the offending quarantine attribute being removed, but I don’t see any way to invoke it. At this stage manually deleting the quarantine stuff is all I can suggest.
Sorry to have so many questions!