The real solution is to use other software than Dropbox, that plays by the rules and cares about its users.
Uh, what?
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.
rename("myfile", "backup_file")
openat(AT_FDCWD, "myfile", O_WRONLY|O_CREAT, 0644)
unlink("backup_file")
Try it yourself:
echo "test1" > test1
ln test1 test2
vim -c 's/1/2/' -c x test2
cat test1
$ echo 1 > test1
$ inotifywait --quiet --monitor test1 &
[1] 14321
$ vim -c 's/1/2/' -c x test1
$ cat test1
2
$ <no output from inotifywait>
$ echo 1 > test1
$ ln test1 test2
$ inotifywait --quiet --monitor test1 &
[1] 14361
$ vim -c 's/1/2/' -c x test1
$ cat test1
2
test1 OPEN
test1 ACCESS
test1 CLOSE_NOWRITE,CLOSE
$ cd ~
git clone <dotfiles repo>
cd <dotfiles repo>
stow <profile|vim|ansible|bin|...>
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.
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.
https://github.com/ctsrc/shell-command-aliases/blob/master/b...
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.
I dunno.
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:
https://github.com/ctsrc/shell-command-aliases/blob/master/R...
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)
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[0], but unless there is some serious amounts of missing context this seems to be glorification of nazism.
[0]: 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?
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
and so on, remove the old symlinks and place the real files in ~/Dropbox/ and then symlink the other locations there. and so on.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/
(Aside: Why not aliases in my bashrc, you ask? Because I use a few different operating systems and eventually realized that rather than trying to unify OS specifics and shared aliases in bashrc it was much simpler to maintain the aliases as wrapping shell scripts.)