The community requested a .dropboxignore file but they chose another solution which I’m sure is reasonable for making the feature more user friendly to non-devs.
This will be immensely helpful for node_modules or build target directories.
Goddamn, stop the world I want to get off
If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). Thus there are no artifacts to gitignore. OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container, and running random shell commands).
To summarize, I think the problem is that node puts packages in your working directory instead of some other location, causing you to have to ignore them. It is reasonable to check in your dependencies, in which case node's strategy is fine. But you can compare this to something like go, which puts all modules in $GOPATH/pkg/mod and if you want to check in your modules, you run "go mod vendor" and it creates a vendor/ directory in your working directory to check in. All of these ignore files exist to work around other packages; it's not git or docker or dropbox's fault that some tool you use contaminates your working directory. Plenty of designs exist for those types of tools that don't.
That is a terrible design, as it makes parallel builds error prone.
1. It might be NFS mounted.
2. Space might be an issue and more difficult to plan for if build outputs are going there.
robots.txt didn't need to know about who the robot was or what the hosting server was.
¹ https://en.wikipedia.org/wiki/Archive_bit
² https://www.samba.org/samba/docs/using_samba/figs/sam2_0801....
On linux you can create an user group named "cloud", and allow dropbox to only sync files that belong to that group.
What i envisionned was more like a "control center" app of all the outgoing (and incoming) pipes from your FS to syncing systems, with both last syncing time, configuration, etc. A little bit like what's already happening for mail and calendar integration into iOS applications, only for files and on the desktop.
Yes, right now Dropbox would probably crash, but that's their problem. I really don't think it's something that should be handled by the OS when they already have a solution for it.
It’s kind of crazy that there are still these low hanging fruit advanced syncing use cases, that would help keep Dropbox’s position as a leader in this crowded space, and they are a multi billion dollar company, but they drag their feet on it for so long. I know they want to keep cranking out mediocre me-too productivity tools that nobody is asking for in case they get lucky and one catches on, but they should really be able to do this too.
https://www.tenforums.com/tutorials/131182-create-soft-hard-...
Or switch to resilio sync, it’s great and selfhosted. Unlimited folders can be used.
still, i'll definitely be making use of this!
https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
I don't do it personally, but I know people who do and it's not entirely illogical.
Why would anyone put a node project in Dropbox to begin with?
Putting every projects in Dropbox with .git is the most awesome feature of Dropbox. With Dropbox's History and Time Machine feature, you will be almost never able to delete/overwrite your work permanently, even by intention.
(I apologize if I sound as if I'm telling you what you should be doing; I am really just trying to understand the motivation behind such a decision - but I fully understand that even if something seems bizzare to me, it's just my personal humble uninformed opinion).
Still not sure if it’s a good idea or not, but not being able to ignore node_modules was the real blocker for me before.
You can only revert changes to states that you have explicitly stored and uploaded. Dropbox does that automatically any time you save a file. That simplicity makes it more reliable. You will never lose anything you saved. And with rewind you can go back to any point in time. The advantage of git comes from its branch/merge features. But for a single developer on a small project that doesn't know git well that's not worht the complexity.
Two things that keep everything in sync:
1. Every two minutes my notesync.sh script runs, which basically does git add --all;git commit -am "New commit";git pull;git push.
2. Vim with AutoSave.vim which saves the document as I write.
Yes, there are a lot of commits, but I don't have to worry about losing anything.
Dropbox actually managed to completely hose every single node_modules folder by the end of the week. It got confused somehow then ended up just splitting all the files up with dates on them as if there was a conflict across hundreds of files.
Stopped using it after that.
Of course, NuGet is far less promiscuous than node, and I'm playing with a desktop app, so there's a lot less ephemeral stuff to have to sync.
But this begs the question: why would the "ignore file/folder" feature itself be useful to non-devs?
Seems like a win on their side.