Add .dropboxignore directory to exclude folders without using selective sync

I would like to see the feature like git has: .gitignore file where I can list specific folders and file names mask preventing them from syncing. I have tons of node_modules folders, *.tmp, *.log files. They are part of the projects and they consuming a lot of space but I don’t need them in my Dropbox. Selective sync is not the solution for this.

I use Dropbox for syncing my development project files but every time all the libraries are uploaded to Dropbox which increases the size of the project by a huge margin. 

It would be very helpful if there is a file like .gitignore implementation for Dropbox sync which will ignore files to be uploaded.

Please implement this feature in the upcoming version, it would be a great help for all of them in the developer community. 

Dropbox has already implemented selective sync in the desktop client so this might not be a very difficult task for Dropbox.

Nobody could deny the utility of Dropbox, it is an incredibly useful tool.
The ability to be able to work on one computer and just pick up where you left off on another is great.

The best part about it is that cloud based synchronization is a feature that can be utilized by pretty much every industry. As a Software Developer I use Dropbox to synchronize and backup code from workstation to workstation with ease.

Developers use a lot of tools to make sure they have some kind of version control to keep track of all the changes that a project has gone through, because things break. One of the most common tools is Git.

Git creates a hidden folder called .git that contains a variety of information needed to help Git catalog and keep track of all your files. If you want to learn more about it you could read this article by a developer trying to make sense of its structure, or you could go directly to Git's website.

I mention Git for two reasons:

• The .git folder could have thousands of files, for a small project.

Screenshot of .git folder

• Git has a special file called .gitignore that could tell the Git program ignore folders or files, recursively.

I commonly use my Dropbox folder, as my active working directory because it is convenient that as soon as I press save it uploads it to the cloud. So if I randomly drop my laptop into a large body of water I would be able to pull out my phone and continue working there as if nothing happened. Then, after completing a certain task I use Git to commit all of the changes I did to my code. Git keeps track of the specific changes I did so if I changed the name of a variable from,

const customersFirstName = "Bob";

to

const name = "Bob";

Git would keep track of all of those changes and let me know that I changed that specific line in my code. Dropbox doesn't keep track of those specifics, and that is fine. I just need it to back me up.

Now there are a few problems with this scenario, remember .git could have thousands of files? If I make a change lots of those files are constantly being modified which trigger a synchronization by Dropbox. Dropbox is usually going to update and index those .git files before it uploads your file and you will sometimes see the Dropbox icon spinning for a while before it makes it to the cloud.

There are situations where I would want to backup the .git folder, but in most cases that is not necessary because I use services like GitHub, and GitLab to store my .git history along with the code it is keeping track of.

So here I am using all of my computers resources to index and upload thousands of files that I don't even need to save on to Dropbox while my laptop is flying in the air getting ready to visit the fishes.

The .git folder is not even the real problem, the real problem has to do with files generated by package managers, or libraries utilized to make the code work. Developers constantly use resources and tools created by others to solve common problems. They often package these tools into libraries that we could just download into our project. For example I commonly use this library created by Facebook called React. So I use a package manager like NPM or Yarn to download the latest version of React into my project directory along with all of the tools and libraries that React relies on to work, because they too rely on other libraries for their library to work.

When you download a library like React.js using NPM or Yarn creates a folder called node_modules and it saves everything Facebook used and needs to make React work. Now this folder is exponentially worse than the .git folder. It is common for the node_modules to have more than 20,000 files! The screenshot below is pretty much the smallest node_modules folder you could have using a React project.

This 20,000 file headache makes my computer kick up its fans and use all of its processing power to sync a node_modules folder and upload it to the cloud. It easily takes 2 hours for Dropbox to finish indexing and uploading this folder. 2 hours of Dropbox consuming your battery and CPU resources. As you could see in the screenshot above it is not because the folder is massive, it is because of the amount of items in the folder.

When developers backup their code using sites like GitHub, BitBucket, and GitLab they usually update the .gitignore file to exclude the node_modules, because you don't need to keep track of and upload other people's code. Especially when you could easily download it again in another workstation if needed using the package manager.

The .gitignore file could also be set to ignore the node_modules recursively, or any file/folder including ones created by package managers such as, Composer, Cargo, or PIP.

Wouldn't it be nice if we could have ignored that folder using Dropbox?

Well we kind of have that with Selective Sync, but that doesn't quite solve the problem.
This 4 year long thread with 93,212 Views 625 Comments kind of expresses why. Dropbox also offers Smart Sync, which mimicks the behavior that OneDrive has where the files are all on the cloud until you click on them, and decide to open / download a file.

 

Dear PhotonWarrier,

I apologize if I offended you.  This string appeared to be about reasons Dropbox should have the ability  for the user to specify files to exclude by filetype, and I was giving another example, at the same trime trying to be polite and give my reasons for using Dropbox rather than alternatives.  This is the first time I have posted to any such discussion group, and I will not do it again.  I have neither the time nor inclination to reply to personal attacks, as you apparently do.  I have plenty of other private venues for communication and to effect change.

The world doesn't revolve around how you and how you want to do things. So glad dropbox works for you, but why are you even posting here? What is your point? To brag about how awesome dropbox is?

In my case, I am working on a project from C / C++ / Fortran and Matlab source code.  After some changes, numerous .o (linux) or .obj (Windows) files are created, and synced with Dropbox.  Although this is not usually a problem for me, I am generally concerned about use of bandwidth and Dropbox resources for it.  (It seems wasteful.)  I thus would prefer to be able to exclude these file types.

Note: I find Dropbox more convenient than say SVN and the like, since it is simpler, with less server installation and maintenance issues, etc.

Highlights:

• Exact same file format as .gitignore and .dockerignore
• Feature could be an opt-in on the official client
• Client then ignores anything in that directory or its subdirectories that match the patterns in the .dropboxignore files up to that point.
• The above rule means that a .dropboxignore at the top of your dropbox would be applied to everything in your Dropbox, but files below that would only apply to their directories and so on.
• .dropboxignore files are synced to Dropbox unless otherwise specified?

I think this would be a really useful feature for software developers that use Dropbox to sync code between their computers because it would keep build artifacts (the various files generated when compiling code) from being synced around, which would speed up the sync process while also using less space.  This could even be profitable for Dropbox because I would bet that many of the people abusing Dropbox in this way are more likely corporate customers with unlimited plans anyway, since it is relatively untenable to do this on most personal plans.

I imagine this could also be good for other creative / professional types like video editors who don't want all of the files that something like Adobe Premier creates when it does an export.

Lastly it seems pretty straightforward to implement as these things go.  Just a couple klocs (kilo lines of code) in the desktop clients would probably do the trick.

In my case, I have lot of videos, pdfs, zips, but I want to sync only the images on to other machines. So, I look for mimetype or wildcard based sync option.

Some files/folders are either generated or transient by nature, and thus it should not be included in the sync in the first place. There should be an ability to right-click on a particular file/directory and click 'exclude' which lets Dropbox ignore it altogether. 

This feature is beneficial for programming people who put their source code in Dropbox, and as part of the code build, tons of generated files should not be synced in the first place. For example, people using Node.js use thousands of files under the node_module directory which adds the stress of Dropbox synching and it clutters the cloud version of the data. 

Ok, @jamak that's fine for small projects or when you're working by yourself.

But what happens when someone else wants to make changes to that code?

The way I'm talking about working is having the actual git repo in the Dropbox folder so you have the best of both worlds.  These tools are not a 'headache' unless you've never used version control.

I think dropbox is fine for individual projects but for anything at scale it's only good for sharing documents here and there, it is definitely not something you would use at scale.