Symlinking configuration files is the approach behind GNU stow. I version my dotfiles in a repository, and on a new system it’s enough to simply run:

  cd ~
  git clone <dotfiles repo>
  cd <dotfiles repo>
  stow <profile|vim|ansible|bin|...>

Every piece of software I use plays well with it. If I were using Dropbox, the announced change wouldn’t break my workflow.

Shouldn't this be configurable at the OS level? If you don't want programs to be able to treat symlinked files differently from "real" files, then don't expose an is_this_a_symlink() API, or at least have the system configurable so this always returns false for certain callers.

It seems wrong to say a program is broken when it's using the OS-provided API in the documented way.

That's a lot of work for what's still only a partial solution. Some symlinks inside Dropbox should get synced as symlinks. But for these use cases, some shouldn't.

Sounds like that should apply to Dropbox, as well.

No, because Dropbox is a file syncing utility so symlinks, which are special files that point to other files, should be synced as symlinks. Replacing the symlink with the target file or directory is obviously broken behavior.

> symlinks, which are special files that point to other files, should be synced as symlinks

How would that work on, e.g., the iOS client? Or a Windows client, even?

Syncing tools are tricky because they bridge and overlap (at least) two filesystems - local and remote. It's not obvious how to handle symlinks there in general case. The default behavior dictated by filesystem abstraction is wrong (would duplicate files and break links). There are multiple other ways to handle it, but it's not clear what's best.

Explain what was wrong with Dropbox’s previous behavior (which is described in the link).

"would duplicate files and break links"

And did the previous behavior preserve symlinks that are located inside a folder in Dropbox and link to somewhere else inside the same folder? Because a symlink-blind program would screw that up royally.