With Hookmark, you can also link to and from Dropbox files that are locally synced on your Mac. Hookmark links to Dropbox can reveal or open Dropbox files on your Mac; this rapid access method allows you to bypass Spotlight, launchers, and the Dropbox website. (Links are good). And you can even send links to Dropbox files to people; recipients can then click on the links to open and reveal the files directly on their own Macs.
This document describes some ways in which you can use Hookmark with locally synced Dropbox files, and some of Dropbox’s idiosyncrasies as they pertain to Hookmark.
Paste links to Dropbox files in your documents
Once you’ve used Hookmark to get the address of a file that is in Dropbox (using “Copy as Link”), you can paste a link to the file wherever you want. Thereafter, you can simply click on that link to access the file. Hookmark will either reveal the file in the Finder, or open it, depending on Hookmark’s General preferences).
Share Hookmark links to files in Dropbox
You can even share Hookmark links to files that are in Dropbox files. Just select Hookmark on the file and invoke “Copy as Link”. Then you can insert that link in an email, text message, or any other communication medium. As long as the recipients have access to the file, they will be able to open it (Dropbox idiosyncrasies not withstanding).
“Reveal File in Finder”
One of the challenges with doing collaborative work in file sharing systems (like Dropbox) or version control systems (like SVN and Git) is that the folder structure was likely set up by someone else. So when you are dealing with a shared file, you may not have a clear sense of where the file resides in Finder. You may encounter this situation if you open the file via Spotlight, a launcher, or a link.
Hookmark helps you find out exactly where an open file is, thanks to its Reveal File in Finder command. You can see the path of the file in the bottom of the resulting Finder window, so long as you have enabled Show Path Bar in Finder’s View menu. This reveals the folder hierarchy in which the file resides.
Dropbox idiosyncrasies regarding conflicted and moved files
Dropbox has a couple of idiosyncrasies that sometimes confuse its users.
- Dropbox sometimes generates conflicted files.
- Dropbox moves asynchronously renamed files into a special temporary location, the
.dropbox.cachefolder.
These issues mostly revolve around the fact that Dropbox is designed to enable multiple Dropbox “clients” to access files. The different clients may be the same user on the same or different devices or different users on the same or different devices (e.g., different macOS accounts on the same Mac, or a macOS client and an iOS client). Either way, a couple of special situations can arise:
- Two Dropbox clients may change the same file at the same time, which can lead to a conflict.
- One client may rename a file which causes the file to be moved to the cache folder on the other clients.
It’s important to note that these behaviors are governed by Dropbox — they are not due to Hookmark. Here, we simply need to be aware of the implications for linking files, and how to deal with Dropbox’s boundary conditions.
1. Conflicted Dropbox files
As noted, if two Dropbox clients access the same file, then Dropbox will generate a new “conflict file.” In this case, everyone who has access to the original file now has two files: the original file and the conflict file. See What’s a conflicted copy?.
If you have links to the original file, they will not automatically be transposed to the conflicted file. However, in some circumstances Hookmark will be able to resolve the bidirectional link. (More on this later).
If you have pasted a hook://file link (a “lexical link”) to the original Dropbox file and want the link to point to the conflicted version of the file instead, here’s what you can do. The simplest (and most typical scenario) is to delete the original Dropbox file (to which the hook://file link is currently pointing), rename the conflicted version to the original name, and empty the conflicted version from your Finder Trash. Of course, you would only do this once you’ve resolved the Dropbox conflict to your satisfaction. The hook://file link should be able to find the new file because it has the same name as the original file. If there are multiple files with the same name and parent folder name, then activating the original hook://file link could now in principle reveal a different instance of the file. (If you have selected Hookmark’s General preference (Reveal hook://file link targets in Finder (rather than opening them)) then when you click on the link, you will see all the files that match the name and parent folder in Finder.
The same principle applies for hook://file links that you may have shared with others, or that you yourself might be using across different Macs.
2. Dropbox moves remotely renamed files to a hidden folder (in .dropbox.cache)
Another idiosyncrasy of Dropbox is that when a locally synced file is remotely renamed (i.e., by a different Dropbox “client”), Dropbox will move your local copy of that file into a special temporary (normally hidden) folder on your Mac called .dropbox.cache. If you fail to realize that the file has been renamed you might think your links have disappeared. But they haven’t. It’s just that you are not looking at your original file, because Dropbox has moved your original file to a hidden subfolder of a hidden folder (.dropbox.cache).
You have probably already noticed something like this happening when you have renamed files in the past. Such actions generate entries in the “My Activity” or “Team Activity” sections of the Dropbox menu. Dropbox will also issue notifications when files are renamed or moved, which you can disable.
2.1 Scenario
To make this more concrete, suppose:
1. On your home Mac, with Hookmark, you link a Dropbox file called “foo.txt”, to something else (say http://apple.com).
2. At work, you rename “foo.txt” to “foo-bar.txt”.
3. At home, you use Hookmark to inspect the links on “foo-bar.txt”. You will find there are no links, because “foo-bar.txt” is actually a new file, created by Dropbox.
Hookmark has not lost your links. Your links are on the same file (“foo.txt”) but Dropbox has moved and renamed “foo.txt” to a special Dropbox folder, ~/Dropbox/.dropbox.cache/. (So while you might think of “foo-bar.txt” as “the same file” as “foo.txt”, they are actually different files.) Furthermore, Dropbox adds a suffix like (deleted 9128028fc8219534c644ba4eb1c4d66x) to the moved file, so the filename might actually be:
foo (deleted 9128028fc8219534c644ba4eb1c4d66x).txt
The ID part (after “deleted”) will of course be different for each file.
Dropbox’s customer documentation is rather thin on all of this. There’s a bit of information about this cache folder on the Dropbox site. Irrespective of Hookmark, Dropbox’s behavior can lead to confusion. See for instance this topic in this case in the Dropbox Community – 266500.
The same principles apply to the renaming and movement of entire folders.
2.2 Implications and work-arounds
If you are working collaboratively on projects, keep in mind that if one of your collaborators renames or moves a file in Dropbox, Dropbox will move your original files into its cache folder. If those files have links, your links will move with them.
If you wish, you can recover your Hookmark links by accessing the original file foo (deleted 9128028fc8219534c644ba4eb1c4d66x).txt. Simply use Hookmark’s handy “Copy All Links” command on that file, and then apply “Hook to Copied Links” on the renamed file.
You can find the moved files in the .dropbox.cache folder. But if you happen to recall the other side of any Hookmark link to the moved file (foo (deleted 9128028fc8219534c644ba4eb1c4d66x).txt), you can use that side to get to the moved file. In our example above, the other side of the link was http://apple.com.
2.3 Future
CogSci Apps is investigating a set of automatic heuristics that Hookmark might later use to automatically deal with Dropbox’s idiosyncrasies.