<story><title>Dropbox ignore file or folder in beta</title><url>https://help.dropbox.com/files-folders/restore-delete/ignored-files</url></story><parent_chain><item><author>NikolaeVarius</author><text>I can imagine a world where a arbitrary directory is filled with gitignore, dropboxignore, googledriveignore, backblazeignore, s3ignore, rsynciginore, dotignore, ipfsignore . . .&lt;p&gt;Goddamn, stop the world I want to get off</text></item><item><author>spectaclepiece</author><text>The most requested feature, to allow a file or folder to be ignored by Dropbox sync without using selective sync is finally in beta.&lt;p&gt;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.&lt;p&gt;This will be immensely helpful for node_modules or build target directories.</text></item></parent_chain><comment><author>jrockway</author><text>I think the problem here is poor tooling that contaminates your working directory.&lt;p&gt;If you look at something like Bazel, all the build artifacts end up in ~&amp;#x2F;.cache (or similar).  Thus there are no artifacts to gitignore.  OCI container builds (&amp;quot;docker images&amp;quot;) are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm&amp;#x2F;container, copying a working directory into the container, and running random shell commands).&lt;p&gt;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&amp;#x27;s strategy is fine.  But you can compare this to something like go, which puts all modules in $GOPATH&amp;#x2F;pkg&amp;#x2F;mod and if you want to check in your modules, you run &amp;quot;go mod vendor&amp;quot; and it creates a vendor&amp;#x2F; directory in your working directory to check in.  All of these ignore files exist to work around other packages; it&amp;#x27;s not git or docker or dropbox&amp;#x27;s fault that some tool you use contaminates your working directory.  Plenty of designs exist for those types of tools that don&amp;#x27;t.</text></comment>
<story><title>Dropbox ignore file or folder in beta</title><url>https://help.dropbox.com/files-folders/restore-delete/ignored-files</url></story><parent_chain><item><author>NikolaeVarius</author><text>I can imagine a world where a arbitrary directory is filled with gitignore, dropboxignore, googledriveignore, backblazeignore, s3ignore, rsynciginore, dotignore, ipfsignore . . .&lt;p&gt;Goddamn, stop the world I want to get off</text></item><item><author>spectaclepiece</author><text>The most requested feature, to allow a file or folder to be ignored by Dropbox sync without using selective sync is finally in beta.&lt;p&gt;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.&lt;p&gt;This will be immensely helpful for node_modules or build target directories.</text></item></parent_chain><comment><author>bsaul</author><text>That&amp;#x27;s probably a clue something needs to be done at the OS level regarding FS integration with cloud syncing systems and permissions.</text></comment>