Child Item

On Mac, aliases in Dropbox to folders within Dropbox no longer work across devices

I'm having the same problem as what the user Robio describes here:

https://www.dropboxforum.com/t5/Files-folders/Mac-aliases-within-Dropbox-used-to-work-on-all-shared-devices/m-p/370300

That discussion went to e-mail before a solution was found. Since I'm having exactly the same issue, I would like to know how Robio's problem was resolved.

My problem is this: Aliases used to work in Dropbox for Mac until recently (maybe a week ago?). Until recently, an alias created on one device behaved as it should on another device. The problem did start around when I updated one device to macOS Catalina, but I'm not sure that it started exactly then.

Here's an example of what I'm experiencing. Suppose that I sync my Dropbox folder between two devices, Device1 and Device2. On Device1, I create two folders in my Dropbox folder:

~/Dropbox/Folder1

~/Dropbox/Folder2

In ~/Dropbox, I create an alias of Folder1 using the Finder menu command File > Make Alias. Then I move the alias of Folder1 into Folder2. So now I have

~/Dropbox/Folder2/Folder1\ alias

On Device1, where I created the alias, everything seems to be in order. Folder2 will appear to contain a folder named "Folder1 alias". As desired, this apparent folder will actually be an alias pointing to ~/Dropbox/Folder1. Doubleclicking "Folder1 alias" inside of Folder2 will open Folder1, as expected.

The problem arises when I move to Device2. There, I again see the two folders

~/Dropbox/Folder1

~/Dropbox/Folder2

But, inside of Folder2, there is a file named "Folder1 alias". Instead of a folder icon, the file will have the generic "file" icon. This file will not function as an alias. It is inert, as far as I can tell. At any rate, on Device2, I cannot doubleclick "Folder1 alias" to open Folder1, as I could over on Device1. Instead, I get the error message "Item “Folder1 alias” is used by macOS and can’t be opened."

Nonetheless, if I go back to Device1, the alias continues to work. It's only on Device2 that the alias is broken. Or, rather, it doesn't seem to be even recognized as an alias by the OS.

My two devices are a Mac Pro running macOS High Sierra 10.13.6 (17G9016) and a MacBook Pro running macOS Catalina 10.15.1 (19B88 ). My version of Dropbox.app is 84.4.170.

Find more posts tagged with

Desktop

Sync

Mac

Insightful

Closed - Partially Delivered

Accepted answers

Robio

I imagine everyone is aware of this, but I still had this thread bookmarked, so I just popped in to say this issue appears to be fixed. I don't recall when it was fixed, but I'm running Dropbox 97.4.467 and aliases are working across devices within shared Dropbox folders.

Now if we can just get them to fix the problem of locked folders/files being not staying locked...

All comments

Walter

Hi @Tyrrell!

As I'd really need an account and device specific view to better advise on this matter (this is exactly why we had to switch to email communication with Rob as well in the post you quoted), would it be OK if I reached out via your Dropbox email address to have a further look into this with all of our tools available?

Let me know here and we'll take it from there. Thank you!

Robio

The one thing that has not yet been made clear to me by Dropbox support is whether or not this is now expected behavior. No one has said one way or another whether Dropbox expects synced Mac aliases to use relative paths...

>alias /users/rob/Dropbox/2019 Budget.xlsx alias

>points to target users/rob/Dropbox/Budgets/2019 Budget.xlsx on ROB's computer

>but points to target users/joe/Dropbox/Budgets/2019 Budget.xlsx on JOE's computer

...which is what was happening a few months ago...

...or if Dropbox has been changed so that now the alias follows absolute paths (i.e., if the path includes /users/rob/, it won't work on Joe's computer.

They've asked me to unlink/relink my Dropbox "to ensure it's working correctly" but first I need to know which of the two behaviors they consider correct.

In the mean time, I've found a workaround: Each user creates their own aliases locally. It's far less convienient because User A has to tell User B where to find everything they might want to alias. But it's better than having to hunt.

AgardD

Hi Folks

I too have exactly the same proble of aliases made between folders in DropBox used to work on MacOSX (for many years) and just recently stopped working. This has to be a generic issue and not specific to any particular user/files, so if there is a solutiuon, it would help teh whole community. Mnay thanks

David

Daphne

Hey @AgardD, thanks for joining the thread here!

Earlier this year, there was a change made in the way that Dropbox syncs symlinks. Please check out this article here for more info on this.

I hope this helps, let me know if you have any other questions!

Здравко

Hi @AgardD,

There could be 2 cases for aliases related issues. So generalization isn't good way - the two groups are very different!

The first case is Dropbox limitation related - fact that anything after aliases can't be "live" sync anymore (since some time). If that's your case, you should reorganize files/directories structure, so no more aliases from inside Dropbox directory, pointing outside this dir.

Second case is about aliases residing inside Dropbox directory and pointing within same dir borders. If the aliases are relative, you should not have any troubles. If they aren't, the picture gets more complicated. Such aliases will work only when Dropbox directory is placed on the same place, on all machines in sync literaly (i.e. everything in the path before "Dropbox" is same)!!! In all other cases an aliases created on one machine will (most probably) fail on another machine.

Let say there are 2 machines and on the first, user name is "UserK" - i.e. Dropbox will sit by default on "/Users/UserK/Dropbox" (for example) and on the second, machine user name is "UserL" - i.e. Dropbox will sit by default on "/Users/UserL/Dropbox". Let say in your account you have a directory and a file inside like "SomeDir/example.txt" and you want an alias to example.txt in the account root. One alias variant is:

example.txt -> SomeDir/example.txt

The above will work in all cases - doesn't matter where is created and where used. That's relative alias. Another alias variant is (created on the first machine for example):

example.txt -> /Users/UserK/Dropbox/SomeDir/example.txt

The above will work only on the first machine, but not on second! That's absolute alias. On the second machine actual absolute file position is "/Users/UserL/Dropbox/SomeDir/example.txt", but the alias don't point there. That's where the problem comes from. This issue isn't Dropbox application related, but the way alias gots created (actually the type).

@AgardD, You can decide where your problem falls to and gets appropriate actions on.

Hope this casts some extra light.

Здравко

What's wrong?... Why?... Am I typing something wrong? :thinking:

@Daphne, Seems you have thrown out my post! Please, tell me why!?

APPEND: Excuse me for the unfounded accusation. Thanks, for the clarifications!

Daphne

Hey @Здравко, it seems that your post got caught up in the spam filter, I wasn't removing your post on my side. I've gone ahead and removed it from there for you.

It probably happened due to the length of your post so please bear this in mind when posting in the future.

Thanks!

Tyrrell

The following solution worked for me: Don't use the MacOS "alias" command. Instead, create a symlink using the command ln -s in Terminal.

So, in my example in the OP, I can create a symlink by entering the following into Terminal:

ln -s ~/Drobox/Folder1 ~/Dropbox/Folder2

This will create a symlink "alias" of Folder1 inside of Folder2. In the Finder, the symlink will look just like a MacOS alias.

However, this solution has two huge defects:

I believe that, for the symlink to work on two different machines, the absolute paths to the source files must be the same. This will fail, for example, if the name of the user folder containing the Dropbox folder is different. (Unfortunately, in MacOS, the ln command lacks the -r flag for making relative symlinks. I haven't been able to find a workaround for this.)
You can't move the source file of the symlink without breaking the symlink. MacOS aliases are more robust. They will follow the source file around if it moves.

So it would still be very good if Dropbox recovered its old ability to use MacOS aliases.

Здравко

@Tyrrell wrote:
...
However, this solution has two huge defects:
I believe that, for the symlink to work on two different machines, the absolute paths to the source files must be the same. This will fail, for example, if the name of the user folder containing the Dropbox folder is different. (Unfortunately, in MacOS, the ln command lacks the -r flag for making relative symlinks. I haven't been able to find a workaround for this.)
...

Hi @Tyrrell,

Actually, you don't have to use -r option/flag to create a relative link.

In you particular case (which differ from the initial in this thread) you can create 'alias' Folder2 pointing to Folder1, both sit in ~/Dropbox using:

cd ~/Dropbox
ln -s Folder1 Folder2

More generaly, if somebody want to create relative link in one place named LinkName pointing to another entry somewhere in filesystem hierarhy like "~/Dropbox/path/link/place/LinkName" and "~/Dropbox/path/actual/place/entry", following could be used:

cd ~/Dropbox/path/link/place
ln -s ../../actual/place/entry LinkName

In such a way link become relative implicitly.

Enjoy!

Tyrrell

@Здравко wrote:
In you particular case (which differ from the initial in this thread) you can create 'alias' Folder2 pointing to Folder1, both sit in ~/Dropbox using:
cd ~/Dropbox
ln -s Folder1 Folder2

Hi, @Здравко. Thank for the reply.

The command

cd ~/Dropbox
ln -s Folder1 Folder2

doesn't work for me.

The good news is that I get something named "Folder1" inside of Folder2. But the bad news is the thing named "Folder1" inside of Folder2 acts like a broken alias. It has the "generic alias" icon. That is, the icon is a generic document icon (not a folder icon) with a little arrow in the lower left corner. Double clicking it produces the error message:

Screen Shot 2020-01-15 at 14.13.58 MST.png

Do you see something different when you do this?

Здравко

Ah... Strange... It works for me....

Another option is skipping link name and rename the link after that, if need (link name is optional). But this would work only when the link and the target are NOT in same place (that's one of the reason, linkname argument to be present - for changing name of the link; by default - same as target)!

ADD: Might help if prepend the names with "./"... Try at least.

If nothing helps, on clear terminal type the lines, I suggested above, and post the content (together your command, exactly as you typed and possible results - i.e. erros) in a code block </> or as a screenshot. So would be clear what's going on.

bobthened

Why would you change that?!?!! The ability to do this was like 50% of the reasoning behind me choosing Dropbox in the first place!!

How can I auto-sync a folder like 'Documents' now? Is it even possible? do I have to do it manually now?

Maybe I should switch to iCloud.

Robio

Now if we can just get them to fix the problem of locked folders/files being not staying locked...