Add .dropboxignore directory to exclude folders without using selective sync

I just realized that I'm hogging up bandwidth with all the temp video files my Adobe Premier projects are creating and it would be most beneficial to provide the feature to IGNORE folders of certain names or file types when it comes to syncing. Also surprised by the age of this thread and how long it's been something asked for.

Come on !

I'm encountering this problem now as a paid user and I'm kind of shocked at the age of this thread and nothing has been implemented in 9yrs. guess it's time to research an alternative service.

-- deleted --

@mweirauch, you're a real life hero.

DelugeIA I think I've actually implemented this a while ago as long as there is no built-in suppport.

https://github.com/mweirauch/dropignore 

I "use" it daily (running as a systemd unit on Linux). It's doing its job. Can't guarantee any big support for it though. My time is kind of limited. I tried as good as possible to support Windows and MacOS, but I don't use these platforms.

Hello Emma,

Thank you so much for the update. I'm glad to hear that Dropbox is considering implementing .dropboxignore functionality similar to how git uses .gitignore files. Such a feature would greatly enhance the usability and efficiency of Dropbox for many users, especially developers who are familiar with and use git on a regular basis.

Gap Analysis

You asked for the gaps between such a feature and the current command line options outlined in the "How to set a file or folder to be ignored" article. The biggest difference for me would be to use regular expressions to automatically ignore certain file and folder names without always having to manually configure them or creating specific instances where I want them ignored.

The extra manual overhead of working with PowerShell to set com.dropbox.ignored values every time one creates a new project or deletes a build folder is onerous and leads to mistakes. This happens often enough that many individuals, like me, do not use the feature any longer. Which I presume causes there to be lots of wasted space and resources for both Dropbox and its users.

Here are the types of content that I would like to be able to ignore without needing to manually set each directory/file when a new one is created:

Temporary and Build Directories that are automatically created and/or do not contain useful information that needs saved, such as with applications like Visual Studio Code.

Local Configuration Files that determine how a program runs on different computers or environments that have shared or synced data directories.

Project Backup Directories and Build Artifacts that are automatically created by programs as they are run, saved, or compiled.

Basic Globbing

I think the ideal solution (for me anyway) would be to have .dropboxignore function as close as possible to the way .gitignore does. Consider the main Dropbox folder as analogous to the root of a git repository. Where .dropboxignore files can be added at multiple levels in the filesystem where they would be relative to the path in which they're contained. The minimum functionality (for me) would be to implement these glob patterns:

Basic Matching : Simple character matching.

• .vscode – ignores the .vscode directory and .vscode file
• build – ignore all files and directories named build

Asterisk ( * ) : Matches zero or more characters.

• *.log – ignores all entries with a .log extension, like error.log, access.log files (or directories)
• backup* – ignore all entries starting with backup, like backup1.txt, backup_2023.zip, backup
• *build/ – ignore all directories ending in build, like sample_build, design_build

Question Mark ( ? ) : Matches exactly one character.

• data_?.csv – ignore files like data_1.csv, data_a.csv, but not data_12.csv

Slash ( / ) : Used to specify directory patterns.

• /debug/ – ignore only the debug directory located at the root Dropbox folder
• debug/ – ignore all debug directories, regardless of their location

Advanced Globbing

While the basic globbing patterns above would meet my needs, these advanced patterns would provide users with flexibility and precision, allowing them to fine-tune their syncing preferences:

Double Asterisk ( ** ) : Used to match directories recursively.

• **/temp/ – ignore all directories named temp regardless of their location relative to the .dropboxignore location
• **/*.bak – ignore all .bak files, regardless of their location relative to the .dropboxignore location

Square Brackets ( [] ) : Matches any one character that's inside the brackets.

• report[0-9].txt – ignore files named report0.txt, report1.txt, ... up to report9.txt
• data_[a-c].csv – ignore files named data_a.csv, data_b.csv, and data_c.csv

Negation ( ! ) : Any pattern that begins with ! will re-include files or directories, even if a previous pattern excluded them.

• *.log – ignores all .log files
• !need*.log – this re-includes the files named need.log and need-it-now.log, even though they have a .log extension

Implementation

I am not familiar with the internals of Dropbox, but just as an idea as to how the developers might implement .dropboxignore without also creating a huge overhead process with every sync...

Create a "pattern cache" in memory that stores all the patterns and their relative paths for all the .dropboxignore files in the main Dropbox folder location. Update this cache whenever a change is made to any of the .dropboxignore files and batch a scan of files against the new patterns in the cache.

When the system calls the Dropbox listener with a FILE_ACTION_ADDED event, Dropbox would compare the file/directory against the pattern cache. If it is to be ignored, Dropbox would then set the ADS com.dropbox.ignored value to 1 so it wouldn't have to constantly check the entity against all the .dropboxignore files or the cache pattern every time.

I understand that there might be technical challenges or performance implications with this approach, but the general idea is to minimize repetitive processing and enhance efficiency.

Implementing a .dropboxignore feature would not only bridge the gap between Dropbox and other version control systems familiar to developers but would also significantly improve the user experience by providing greater control over syncing behavior. This has the potential to save bandwidth, reduce errors, and enhance overall productivity.

Thank you again for the update and the opportunity to provide my perspective.

— Jeff Sorensen

Justin from Just Front-end- NPM was just ONE of the use cases, but there are many as documented through the history of this request.  I would argue therefore that even though you may have a point (technically), it's still a relevant request for other use cases which may also end up resolving the NPM issue as a side effect.

Anyway - I just add my 2c these days for fun as I am no longer a dropbox user - and the way we got treated with this feature request was driving my decision. I ended up using alternatives that provide this feature out of the box. I doubt I will ever use dropbox again.

I joined this thread years ago. I've also used the various concocted solutions, ie. 

Recently though, I came to a different conclusion.

It's not a Dropbox problem.

It's an NPM problem. Or an OS problem, depending how you look at it. We can't sync millions of files in split seconds, and taking the node_modules outside of our projects, isn't an easy task, nor would it even work, given the peer dependency problem. Dropbox though didn't create that problem.

If one of the other cloud providers had implemented the gitignore, maybe Dropbox would have had jumped on the request, years, and years, ago. They didn't. Nor did Google Drive. Nor did OneDrive.

In the time being, pulling from CDNs instead of using NPM has been my solution.

+1

Sam DBXplease stop saying this. It's been way to long to act like you are considering "providing a solution that meets your needs."

THIS A SOLVED PROBLEM WITH AN INDUSTRY STANDARD THAT IS WIDELY USED! Stop gaslighting! Just implement the feature and stop pretending you're working on it! You're not! We know you're not! If you were, it wouldn't take nearly a decade to do!