You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Key Command/Shortcut to "Copy Dropbox Link" from Mac Finder.
I copy download links all day from the Mac Finder. It would be great to assign a key command so that you can highlight a file in your Dropbox via Mac Finder, and press a key command to copy the link ...
Update (2023-01-17)
I've moved the script to a repository and expanded on the instructions.
I wanted this now, so I wrote a Python script to get the URL from the command line and created an Automator QuickAction that calls the script with the selected file(s) in Finder:
Now, ^⌘L copies the Dropbox URL of any number of files selected in the Dropbox folder.
I should clarify, that screenshot is of my original workflow, before I changed the script to "$0"
Ack, that's my error! It should be "$@" like you had it, I'm sorry. Please change it back.
Just to be clear, when you're getting this error, are you pressing Run within Automator? If so, that won't work. You need to do the next steps to set up the Finder keyboard shortcut. That way the Workflow will be run as a Quick Action via the Services menu and thus have selected files in Finder to pass into the Quick Action.
Gene_ParmesanSuccess! Previously I had been using a Keyboard Maestro macro to run the Automator workflow, but I've just tried triggering it from the services menu with a keyboard shortcut, and voila! It works!
I'm curious how the two methods differ. I had used KM to run your previous version of the script without any trouble. In any case, this method works great and the link seems to be generated much much quicker than before! A massive improvement -- thank you again for this!!
Huzzah! So glad we got there in the end, thanks for helping me debug the script, LOL. And I'm really pleased to hear it's faster now!
My guess is that the difference comes from this version of the workflow requiring Finder items to be passed in at the top. Previously, I was using a Get Selected Finder Items action, which was resulting in links being duplicated given the "Workflow receives files from Finder" preamble. But if you add back that Get Selected Finder Items action and then go back to using KM (and I presume set the workflow to receive "no input", since that's how you'd now be using it)… I think it would work that way as well. You can read up on this a bit on AskDifferent.
I'd be interested to hear if my hypothesis is correct. 😀 I had assumed these two approaches were completely equivalent, but perhaps using an action is actually more flexible.
That was it! When I restored "Get selected item from Finder" and changed the input to none, my Keyboard Maestro macro worked. But after a quick and dirty test, it looks like it's just a hair faster to run the workflow as a service, so I'm going to keep it that way after all.
Thanks Gene_Parmesan !!
Great, glad we could lay that mystery to rest. Yeah, I'm not surprised that it's faster via the Services menu. As far as I understand it, having that extra Workflow step means another AppleScript invocation, and AppleScript is notoriously sluggish.
Gene_Parmesanthe update did the trick! Thank you!!
Just discovered another small issue, which I have now fixed. The recent Dropbox update changed where the folder is located. Files are now actually stored in ~/Library/CloudStorage/Dropbox, and ~/Dropbox is just s symlink. This means that passing a path to a file within ~/Dropbox will fail.
Easy enough fix, and it will only affect users trying to get links from the command line. (It looks like Finder passes the resolved path in ~/Library, so if you never plan to use this from the command line, then you should be OK without an upgrade.)
This has been working so well for me, thank you Gene_Parmesan!!
FWIW, I wanted to report a small quirk that I've noticed, which is that a link can only be copied once the file has completed syncing. If it hasn't completed yet, I get the following error message:
Interestingly, if I right-click the file and use Dropbox's "Copy Dropbox link" action, it will work even if file hasn't completed its sync. Do you have any thoughts as to whether or not this is something that can be addressed by the script, or is this a limitation of the Dropbox API?
Hi dhermanq, glad the script is working well for you! I've had a look at the dropbox Python API docs for the function in question, and I found an option I hadn't noticed before:
pending_upload: If it’s okay to share a path that does not yet exist, set this to either PendingUploadMode.file or PendingUploadMode.folder to indicate whether to assume it’s a file or folder.
And indeed, when I upload a large file without this setting and request a link before the upload is complete, I get the same error as you. However, when I set this to PendingUploadMode.file, the link is generated anyway. When you use the generated link before the file is fully uploaded, you get this placeholder UI:
It's noteable that this option is available when using sharing_create_shared_link, but NOT with the alternative sharing_create_shared_link_with_settings which is used in the script posted by Здравко. So you'd be running into this with either script. Note also that the function description for sharing_create_shared_link says: "If a shared link already exists for the given path, that link is returned." (The function without settings which I'm using, though, is marked as deprecated. If anyone knows how to enable PendingUploadMode with the new-style call, I'd be happy to accept a PR in the repo. I don't immediately see how to do this after looking through the docs and the forum.)
Anyway, now that I've found this alternative, I've pushed a fix linked to issue #10 in the repo. Let me know if that fixes the behavior for you!
It's never good idea methods, declared as deprecated, to be in use. 'sharing_create_shared_link' is such a method! The same effect has a preceding dummy upload though. My script is just an example, that's why not feature rich, but if you want to improve yours, better include preceding dummy upload as an option instead of using deprecated things that can be dropped at any time. Such methods are for back compatibility only, that let some time for developers to adapt their codes, and not supposed to be used in new code!
Add: Gene_Parmesan, One more thing you may want to update is new links conception that's rolling out currently. Probably soon all accounts will start generate new links and the query replacement, as you have implemented it, will stop work!
I am not doing any uploading, I'm only getting shared links. Oddly, the docs don't list this method as deprecated, it's just a warning that is supposed to be printed when you call it. (But I'm not seeing it for some reason, I only noticed it because I looked at the code!) And it's been "deprecated" for 7 years now.
Anyway, the whole thing is a bit perplexing, so I've opened a new thread about it.
As for the "new links" concept, I'd appreciate a pointer to some documentation on what this means. I don't know what change you're referring to, since I'm far from a Dropbox expert.
