But the solution is simple, just switch around which is the real file and which is the symlink.
So where you used to have symlinks like
~/Dropbox/.bashrc -> ~/.bashrc
~/Dropbox/.vim —> ~/.vim/
~/.bashrc -> ~/Dropbox/.bashrc
~/.vim -> ~/Dropbox/.vim/
This is similar to what I do with some of my files in ~/bin/
Many of the files I have in my ~/bin/ are symlinks to files that live in git repositories.
For example, I have a few “alias commands” (shell scripts that wrap a longer command) in ~/bin/
~/bin/st -> ../src/github.com/ctsrc/shell-command-aliases/bin/st
The real solution is to use other software than Dropbox, that plays by the rules and cares about its users.
Following symlinks is the default behavior for unix programs that requires extra effort to work around, why would it be "magic", or an antipattern?
It’s really simple: symlinks are symlinks and should be synced as symlinks. Now they are.
Just like how when you tar up a directory, the symlinks are stored as symlinks, not as the files they point to.
I fixed this by integrating all of personal software dev together into a singular build system that will run my sync script, which also manages the various package managers on my systems, once a day if it hasn't been run. Idempotency is my best friend.
Having system files in Dropbox as the source of truth, and symlinking to their canonical locations, is a poor workaround. Does the software work for you, or do you work for the software?
As another comment suggested, one can use cron and rsync to the Dropbox folder. This at least maintains the priority of the system files being where they should be.
Or, one can use any other software that respects and works for the user. Syncthing is great.
GNU Stow (already mentioned here) and NIX are examples.
This sort of snark is unnecessary. Everything has tradeoffs. Have you ever had someone accuse you of not caring about your users? Do you know how it sounds from the other end?
This is exactly why I used this language in this case: because it is just so blatanly obvious that this change is something they have done for whatever other reason (perhaps to make their life easier?), but not to care about its users. This is not even a new feature, this is something that has already worked and a lot of users were depending on. They are literally breaking many setups and are forcing the users to expend time and resources to immediately (was there even a warning) come up with other solutions and re-create their configuration.
I think that if they cared even a little bit, with whatever other reasons they had for this change, they could easily make it an option with a sane default, instead of a locked functionality.
Dropbox screws up - and you no longer have your core config files needed for basic system operation.
Personally I prefer symlinks because it makes it easy to tell what files I have directly under source control. But hard links should work fine and should mean that even if Dropbox mysteriously decides to delete your files from your ~/Dropbox/ directory you will still have a local copy of them and be able to use your system without interruption.
And how do you imagine that it would happen that Dropbox would randomly trash the contents of your files? And if it was that buggy why the bug be limited to just the files in your ~/Dropbox/? By that argument you might as well say that it could trash any file owned by your user. And if you believe Dropbox to be likely to have such serious bugs, why just Dropbox and not other software you are using? For example Chromium or Firefox? Or any other piece of software?
Seems less like a serious concern and more like trying to think up any imaginable thing that could conceivably go wrong no matter how unlikely.
Lots of ways. Suppose they tried to implement a 3-way merge system (a la git) to resolve conflicts in your synced files. It's easy to see that going terribly wrong if they implement it incorrectly.
It's proprietary software as a service. That means they could conceivably make a breaking change like that without even notifying you, the user, and cause data loss.
Scenario- win7, win10, mac, phone had a folder called “admin” with multiple sub folders. Turning off syncing on a sub folder on one of these ended up deleting the folder and all it’s contents on all the machines. Renaming or moving folders has also resulted in unexpected deletes.
OneDrive is not Dropbox, but it reminded me not to do this with important files regardless that Dropbox has been pretty solid for 10+ years.
I’m back to rsync from “source” and not using OneDrive for workflow.
Reversing the symlinks means Dropbox becomes the source of truth and the dependency on Dropbox increases.
Personally, I used this to easily backup my Downloads and Documents.
They just broke all clients using this feature.
On work computers I do the same but with git.
/.bashrc -> ~/Dropbox/.bashrc
~/.vim -> ~/Dropbox/.vim/
- writing the updated file under a different name
- deleting the old file
- renaming the updated file
(I think that’s a fairly common strategy. I tried checking whether vim uses it, but got lost in https://github.com/vim/vim/blob/master/src/fileio.c; that file is too large to comfortably read on an iPad (try guessing how many lines of C it takes to ”Read lines from file "fname" into the buffer after line "from"”)
I would consider the behavior you outline to be an editor bug. Symlinks are pretty important and any editor that would destroy a symlink and replace it with a regular file is clearly misbehaving software IMO.
openat(AT_FDCWD, "myfile", O_WRONLY|O_CREAT, 0644)
Try it yourself:
echo "test1" > test1
ln test1 test2
vim -c 's/1/2/' -c x test2
$ echo 1 > test1
$ inotifywait --quiet --monitor test1 &
$ vim -c 's/1/2/' -c x test1
$ cat test1
$ <no output from inotifywait>
$ echo 1 > test1
$ ln test1 test2
$ inotifywait --quiet --monitor test1 &
$ vim -c 's/1/2/' -c x test1
$ cat test1
git clone <dotfiles repo>
cd <dotfiles repo>
It seems wrong to say a program is broken when it's using the OS-provided API in the documented way.
How would that work on, e.g., the iOS client? Or a Windows client, even?
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.
Do you really care if the developer of a packages morals line up with yours? I care if they are going to compromise my computer. I can if it works. I don't give a damn if they are a nice person.
Apt/gem/npm/pacman/pip installing a package doesn't materially support the developer. Nobody pays them a nickle for every install and I'm not going to start vetting the ethics of the authors of the 2400 packages installed on this machine anytime real soon.
What, because some involved people did things that might be objectionable in a way that doesn't affect their code? Why should I care?
In this case, submitting code changes to a project like suckless might be not such a good idea, as you might not be welcome.
And as a result, you might want to avoid such projects.
(Also, referring to literal nazi symbolics as "not in vogue" is quite concerning)
This had me confused for a moment, but then I realized that you probably thought st was referring to https://st.suckless.org/
Don’t worry, it’s not.
st on my systems is an alias for git status.
Even so, I think that twitter thread is somewhat confusing because they draw parallels between walking with torches and nazism (?)
In my country, torches are often used in peaceful protests against racism.
But the email thread that was linked to seemed to be nazi apologetic for sure. So I guess if one was to consider using their software one should perhaps look more into what kind of things the people involved in that project stand for exactly.
> In my country, torches are often used in peaceful protests against racism.
They were doing torch marches in the same places where the nazis (like, literally Hitler's party in the 1930s) were doing their famous torch marches.
That's hard to justify as anti-racism protest while also using hostnames based on Hitler's residences.
> st on my systems is an alias for git status.
Ah, that's an interesting shortcut.
In that case I agree with you, that is a rather clear expression of nazi sympathies on the part of the people that would do that.
>> st on my systems is an alias for git status.
> Ah, that's an interesting shortcut.
You might be interested in my other git shortcuts also. This README has all the details you need about them:
Are you really suggesting that one should audit their use of open source tools regarding the political correctness of the free time activities of its developers?
On the social media site screenshotted, users can choose whether to post personally, or enable for a certain post an official title. The user posting the "cultural marxism" post manually, explicitly, and intentionally enabled the "suckless.org developer" title for that post, making it an official statement of the project.
That’s not free time activities, and naming systems after hitler’s residences and making torchhikes in historic locations isn’t about "political correctness" anymore.
I’m also not suggesting one should audit all their software, but it’s good to know about what kind of software one is running.
I'm normally very much against enforced political correctness but this seems to be way beyond that.
I hate nazism. I'm not particularly happy with people calling other nazis that aren't either, but unless there is some serious amounts of missing context this seems to be glorification of nazism.
: for a starter the obvious implications of crying wolf when there is no wolf.
It is. It is open source. Just because it's public doesn't make it non free time.
> I’m also not suggesting one should audit all their software, but it’s good to know about what kind of software one is running.
How does all this impact the software? Did this "kind of software" get "infected" by the views of its authors? How?
I used to think that the good thing about open source software is that the result is neutral and open for anyone to inspect, improve and use.
How is an official conference organized by the project itself "free time" and not related to the project?
> How does all this impact the software? Did this "kind of software" get "infected" by the views of its authors? How?
Open source is also about open community. With a project like suckless, I know I wouldn’t feel comfortable contributing to it, opening issues, or trying to submit pull requests, because I wouldn’t feel welcome in their community.
In an open source community, where many of us would end up trying to give back, that’s a major factor in whether to use such a project.
I'm not saying that it is not related to the project. I'm saying that they are conducting the project in their free time.
> Open source is also about open community.
If you see how different people talk about their "tech stacks" (i.e. talk to a node module maintainer and a kernel hacker and you'll see the differences), it is a misconception that there is "one" open source community. Luckily, there are many.
> I know I wouldn’t feel comfortable contributing to it
Then don't. It would even understand if you'd advise people to avoid such conferences. But advising people, i.e. non involved end users, not to use the software is a bit far.
Yeah, that's the point. That the community around this particular software has a rotten core.
If improving that software is not possible in the same way as with other projects, which it is with suckless for some kind of people, then using the software is impacted by that.
It is surprising to me that one suggests to choose software on the political views of the authors and not on technical considerations.
This has nothing to do with me being German nor did I support or endorse those (admittedly strange) views. All I'm saying is that it has nothing to do with their software.
Actively contributing or joining a group would be an indication that you share views with them.
But having installed a piece of software maybe through a package manager? Simply using it?
That was my whole point.
Also, for the rest, I totally agree with you.
Better make that all the popular non-ext4 filesystems, 2 of which are default filesystems on the 2 major Linux-distributions out there (Red hat & Ubuntu).
What on earth were they thinking?
They were amazing software and now they’ve eroded away most of it such that they have very little over their competitors.
At this point the only reason I stay is they sync macOS extended file tags and comments; both things I make heavy use of. To my knowledge Syncthing doesn’t, nor Google Drive for that matter.
iCloud Drive does that too, and should be good enough if you stay within the Apple ecosystem, can’t say about support/reliability on other platforms.
That’s the rub really. All my machines other than my main Laptop run Linux and my phone is Android. I’ve really set myself up for pain.
But in 2019 it is basically an inferior and antiquated tool for syncing your own files.
I moved to the open-source SyncThing some years ago, which gave me:
1.) the ability to sync any arbitrary set of folders I want, which of course completely obviates the need to care about things like this issue (i.e., no need to use symlinks to sync other folders, because you can just sync those folders themselves)
2.) the ability to actually sync folders that contain symlinks, as many types of software projects do (Dropbox and many other purported sync tools can't do that, which means there are many common types of folder that they can't sync without corrupting them by replacing the symlink with the contents of the symlink destination) EDIT: Or, have they fixed that now, and is that why they are making this announcement? I am not sure. Back when I used Dropbox for syncing, it couldn't sync a folder containing a symlink, but this may no longer be true. (?)
3.) better sync reliability
4.) better sync performance
5.) completely superior security story; end-to-end encryption means you are in control of who can access your files (no access for employees, governments, etc)
The tradeoffs are:
a.) a little bit more work to set up (but it's really just a little bit... I walked my dad through it over the phone... basically the same amount of work as getting your credit card billing setup on Dropbox)
b.) weaker story on mobile, no iOS app
c.) no "cloud" so you have to do your own (e.g., leave an iMac running 24/7 back at your house or something)
All in all, after 2+ years I am extremely happy with Syncthing, and I don't think products like Dropbox have a very strong case to exist anymore, at least not for the original purpose of syncing folders full of computer files.
That problem has now been solved better, way more securely, and for free. (Which is probably why Dropbox seems to be trying to pivot to become some kind of enterprise team commmunication hub.)
 https://syncthing.net (if on a Mac just install the Mac app and it will install the other components for you)
> That problem has now been solved better, way more securely, and for free.
You haven't accounted for the cost and maintenance of the 24/7 iMac (or VPS) if one doesn't already have that, and not everyone does.
I'm also a happy SyncThing user but I wouldn't say it's as easy to use as Dropbox for the general user.
I suspect that most people with smartphones also leave them on 24/7.
True, but unlimited data plans do exist and I've found that more often than not, one laptop finds another laptop over the internet than using the fallback of using cellular data over the phone to sync.
I just installed the F-Droid android client yesterday, it syncs over both Wi-Fi and cellular data by default since until you add devices/folders, it won't spend any mobile data at all, which is when it prompts you to make that choice.
Hopefully something gets worked out eventually.
They aren't opposed to it, and they give advice and helpful comments to those who want to try it.
But, this is just one of the many places where Apple's authoritarian platform model shows its disadvantages. Syncthing is written in Go, but Apple didn't provide a good story for doing Go development for iOS, and because of their lockdown rules, nobody other than Apple can.
Therefore, to get Syncthing running on iOS, you'd need to do a complete from-scratch implementation in one of the languages Apple allows you to use. So it is a relatively huge effort. A few people have tried, but nobody's completed anything very compelling.
An average computer doesn't really consume more than a couple 100W light-bulbs worth of wattage when idling, and so if you live in a region where energy is clean and cheap (e.g. myself in Montreal) then there is very little overhead.
On the other hand, there are certainly plenty places around the world where energy costs are much higher to both the consumer and the planet, so that is indeed something to consider.
Edit: and yes, i have 24/7 machines.
There are many ways to do it, but in my case, I back up my main "on 24/7" workstation (which has all my sync'd folders, whereas my laptop and other machines have a subset) with Arq→S3 snapshots-over-time. And also Backblaze as a secondary backup, just in case, and while they don't support snapshots, they do let me back up 14TB for $5/month.
Am I right that Duplicati only works with B2, not their cheap $6/device personal backup stuff? That would be a significant price increase. At that price I'd probably prefer the $1/TB/Month of S3 Glacier Deep Archive, though restoring at ~$100/TB seem quite painful.
Duplicati doesn't work the other backblaze products, just B2. You can also use S3 Glacier, and I think it's actually one of the better use cases for it tbh (I just avoid giving amazon money all-together).
You really buried the lede right at the bottom didn't you? The entire point of a Dropbox type service is off-site cloud backups. If I have to buy and maintain a second server and leave it running 24/7 in my house (i.e. I'm not insulated against losing my data if my house burns down or a burglar breaks in) then clearly this product is providing an entirely different and far more limited service than Dropbox and is not an effective replacement for it.
No, it isn't. The entire point of Dropbox is having a shared folder on multiple devices that keeps itself in sync. "Cloud backup" aspect is a side effect, but it's too easy to break that "backup" accidentally.
WRT. SyncThing, it's not for regular people not willing to expend any effort at all to set it up and keep it running, but in our adtech-driven startup economy in technology, these regular people are doomed to be ripped off and abused. Such are the aggregate ethics of this market.
Actually back then Dropbox was pretty neat an there was no way my dad could implement that himself, and even for us nerds, it would be a major hassle to set up and keep running... so Dropbox had real and obvious value.
My point replying here was that now, under some circumstances anyway (see below), it now really is quite trivial for regular people not willing to expend any^W much effort at all to set it up and keep it running. (It is less than one minute of one-step installing and then configuring Syncthing.)
However the thing I missed, as pointed out in some of these comments, is that not everybody has a machine at home that is on all the time.
I do, and I set up an iMac for my dad and sister etc and told them to just leave it on all the time and just let the screen sleep after an hour.
I think a lot of people do that, and I think it is a good idea in general, but if you don't want to do that, then yeah in that scenario Dropbox still does have some value.
This quote has haunted me for quite some time until I realised the best way to solve the Dropbox problem lay in the UNIX philosophy with at least: a storage component + a sync component + a web UI component
At that stage, it becomes a game of lego in a healthy ecosystem of tools. As I was just missing the web UI component, I built it: https://github.com/mickael-kerjean/filestash
My experience is the opposite. I don't know a lot of people who have a machine turned on 24/7.
Additionally, I think that leaving a client machine running 24/7 is not a good idea, considering heat/consumption, (potential) noise and wear.
Also, I think other people missed one point in this discussion. If one has a local filesharing server, and carries a machine (laptop/tablet) out, they need to sync immediately every time when they come back home. It's a hassle.
I do have a 24/7 server, and used to have a filesync service on it, but all things considered, a free Dropbox account turned out to be the most conventient choice.
(Strong disagree that it's a bad idea though; it's super handy, all your windows are just where you left them and your email is already there before you sit down at the computer. iMac machines in particular are highly reliable and will happily run continuously for many years beyond the time frame you'd still want to use them. Seconds matter.)
But anyway, the main point of this reply is to say that with Syncthing you never need to sync immediately, or manually at all, in this scenario. If I take my laptop out and work at a cafe or something, it syncs continuously and flawlessly, and when I get back home my iMac Pro is already totally up-to-date.
It's only when you do some work with huge files on an airplane with no connectivity, or something like that, where you might need to make sure you turn it on again when you land and make sure it is on and connected to the internet to make sure all the changes get synced back to all the other machines.
If you have at least one always-on machine, Syncthing is just as convenient, but objectively superior (security and price being the biggest two). If you don't want to or can't have one always-on machine, then that might be a reasonable use case for Dropbox for file sync.
If one applies changes on a machine, then switch to another, they must ensure to leave them on for a brief time to allow syncing, then turn off the previous one. If they don't do this, they'll (likely) get conflicts.
If one's requirement is not to entrust a 3rd party with one's own data, of course, cloud/proprietary solutions are excluded, but to expect open/local solution to be as convenient as the former, is just false.
If you're using it to collate photos from different sources for example, that's fine. If you're trying to collaborate on a document, yes, of course, it's the wrong tool.
If you only have a single device you're probably not in the market for a cross-device file synchronisation program!
(Like Dropbox, it's not really a backup tool - bad data will be replicated just like good data. Also like Dropbox it does have versioning, but that's still not really a replacement for regular snapshotting IMO.)
(Malware is also why I really like Dropbox’s minimum retention period since it breaks the ransomware model)
For dead-easy "regular person" backup, I would recommend something like Backblaze.
From the first paragraph:
"As of mid-2019, Dropbox no longer follows items outside of your Dropbox account that are linked to by a symlink."
In the next paragraph is explained how symlinks linking to files within your Dropbox folder still work.
Does it now just sync the symlinks as-is, so if you have a folder full of symlinks, you just get the same folder full of the same symlinks (as if you had zipped the folder, and then unzipped it on some other machine)?
If so, that is a big improvement from the old days IMO, though it would unavoidable cause the issue being discussed here.
IPO dates of most (once) cool tech startups signal time to search for replacement and time of approach change by them.
I'm glad I did. Now my phone and tablet are first class citizens
when syncing and I can have multiple roots shared between
different devices. I wish I switched earlier.
The only thing that bugs me about my Syncthing setup is that it's annoying to find a file in one of my sync'd folders from my phone (which is iOS, so no Syncthing client).
I don't do that much, but every once in a while you really want to — and in modern times, we mainly want to find files via searching for file content.
This looks great, and I will definitely try it tonight!
I switched to Seafile, backed by Azure blob storage - so much better than Dropbox. The Windows client barely uses any CPU, sync conflicts only occur when I'd expect them to, and of course you can sync files regardless of whether they are in a fixed "Dropbox" folder.
I have Seafile and Minio running in containers, so it was super-easy to setup, and is a doddle to upgrade too.
Haven't looked back!
I recently switched from Dropbox and wanted to clean up a folder of some old one-off scripts in groups of year-created. I had to pack them in 7z archives and sync those in order to have the scripts available in multiple machines as I wanted them.
It's disappointing when a piece of software is almost perfect, except from that one little thing you need and completely ruins your workflow.
I'd love to contribute to Syncthing, but I'm tired of learning new languages, frameworks and paradigms for such trivial (IMHO) changes. I never thought I'd be missing the elegance and simplicity of plain old C.
Also, is it really an upgrade?
When Dropbox stops syncing symlinks to outside files and directories, the situations becomes a lot better. Placing node_modules/ or venv/ directories outside the the dropbox and just placing a symlink here, makes Dropbox a good option for code backups, again.
storage hardware is incredibly cheap, relatively speaking, so for Dropbox the main thing is not reducing costs, it's convincing people to pay in the first place.
I have, however, use folders under Dropbox to sync local files into (make a change, sync over into Db); or even have a Db folder for git repos added as a remote (commit a change, git push dropbox branch.)
When Dropbox allowed Symlinks, and recommended Symlinks, it fundamentally changed the meaning of what Symlinks were. It focused it on its technique to emulate and a way to direct Dropbox to synchronize folders not necessarily in the Dropbox folder.
Because now I can’t have a symlink in my Dropbox pointing to a machine-specific file outside the folder (like an env-vars file that’s different between MacOS and Linux)
Why they are doing this recently?
Now symlinks are understood by the server, but ones targeting content outside Dropbox break.
Or could they be changing the use case of the platform to sharing files instead of backing them up.
A good test case is a MacOS Application Package. These often have internal symlinks that most users never notice, e.g. from "current" to a version of included software. A sync program that replaces the symlink with its contents simply bloats such an application, but it still works. A sync program that ignores a symlink breaks the application. In either case the mistake is "thinking" about the symlink rather than treating it like any other file.
There's still only one sync program that I know of that handles every issue like this correctly: Unison, written by a prominent computer scientist with astute community feedback. This is collectively a smarter brain trust than the sanctimonious support folks who have resisted my feedback at various sync software companies, sure that their unique approach is correct. Not only does Unison correctly handle symlinks, it also has a notion of an "atomic" directory, so that one doesn't for example hose a git archive modified at both ends, or a sparse disk image modified at both ends.
I use DropBox when I need the integration, to iOS or sharing with others. I sync the guts of each machine, for my private work, using Unison.
With the old Dropbox, if you did the following:
1. machine A: clone a git repo that contains a symlink
2. machine B: wait for repo to sync
3. machine B: git status
You'd see a "type change" in the git status output. If you did git checkout you'd get your symlink back and it wouldn't interfere with machine A.
Which was all fine if you had your file contents synced in git or similar, but if you had it set up by hand it was a huge pain in the rear (because you'd have to locate the bad symlinks and restore by hand manually).
It would also be interesting to see if on Windows it handles Junctions as hard links or soft - basically does this only affect shortcuts on Windows or also catch the less used filesystem option.
I've been using Dropbox for years but this change means I need to re-organise, so may as well look at other options at the same time. I really enjoy the ease of right-click to share, if any other service has replicated that.
The only thing I still do use Dropbox for is the share-with-whoever functionality, too. I'd be curious to hear about alternatives for that as well.
(To me it seems pretty orthogonal to syncing folders across machines, though, and I'm fine with and probably prefer using different tools for that. Which I guess I am doing, since I use Syncthing for syncing and Dropbox for sharing.)
Where i need longer duration i just use gdrive
For example I use it to synchronize the photos from my phone to my Laptop, whenever they can reach it other either by being on the same network or by connecting to the global syncthing "introducer" system, they start syncing.
Having a "cloud" system becomes useful if you need to share a file with someone who's not online with you at the same time, which is a pretty big use-case I supposed. But that is a problem that any alternative that is software only will need to solve via some service.
Nextcloud for example or also Seafile. Both have nice clients, but require some sort of server, whereas with syncthing the cloud part is optional.
Resilio Sync is decentralized as well. And lets you setup encrypted folders, so only peers with the password can decrypt them, but other peers can take part in the syncing. So I can run an instance on a VPS and not worry too much if it gets compromised. I find its Linux support lacking and wasn't as reliable as Syncthing for me. I'm going to try it again sometime.
Seafile. Centralized server, can do encrypted folders. I'm going to look at this one again, but found the sync took a real long time, and I don't think it synced file mode bits.
Nextcloud. Centralized server. Can do encrypted folders. Seemed OK, but didn't do mode bits.
Currently I'm using Syncthing, where my central always on machine is my home server which would be running anyways. I like the idea of having a 'central' server in the cloud, but need that to be secured in a way that Syncthing can't do. So I'm not sure its my permanent solution yet.
I also use Unison for much larger folders, like my code directories.
But Syncthing doesn't let you share a link to a file. For that there might be OwnCloud-based solutions.
The only reason i have dropbox on my workstation is so that i can
ln -s /media/user/ssd_drive/results/bigstupidfile.tar.gz ~/Dropbox/user/
Personally I'm moving to Resilio Sync since these days I only use Dropbox to sync prefs and some files between devices. The idea of sharing the same folder between many users can be disastrous.
I've been using Dropbox for years but this change means I need to re-organise, so may as well look at other options at the same time.
If you do have a server peer though, you can also use it to ensure that there's a second copy of all synchronised folders (other peers can safely have different subsets), and thus as the one place from which you can take snapshots to backup elsewhere. (Syncthing does have versioning a la Dropbox, but IMO just like Dropbox it's more about sharing between people/devices, and an automated regular snapshot should also be taken.)
Being able to backup my home directory in its entirety and sync a subset of it (ex code projects) between machines is handy.
If you want to sync default MacOS folders that you can't delete in Finder (Pictures, Movies etc.) you can delete them using sudo in terminal and recreate them as symlinks. I've even done that with Desktop (I just keep plain text files there) and it's been working fine for a few years now.
The result was continual sync, 100% cpu and growing RAM use (past 20GB). I had to eventually delete the link and just copy the files over manually when they were done being created.
As long as the symlink is inside the ~/Dropbox folder, pointing to a file/folder also inside the ~/Dropbox folder, it works. I can open the file/Folder when tapping on the symlink on mobile Dropbox.