Add .dropboxignore directory to exclude folders without using selective sync

[Tom_M]

Please please please can you add a feature that allows folders to be excluded from the Dropbox account (on windows and mac). For sure I'm not the first person to request this, but I'm yet to find a good explanation of why it's not there. A quick google search reveals loads of people also looking for the same feature. I really like the workflow I have with dropbox, but it's getting to the point where I might switch providers in order to allow better selective sync.

I've seen hackish solutions using selective sync, but it would be great if this could be done in one of the following ways:
- global pattern matching eg "node_modules"
- a marker file in the directory like .dropboxignore
- a simple right click context menu "Ignore this folder"

Other than that, keep up the good work. Cheers.
Tom

[Emma]

Hi folks, 

Thanks for your feedback on this.
While ignored files delivers for some of the use cases here, I appreciate it does not for all. 
We'll be taking another review of this thread to isolate use cases for a .dropboxignore file feature in particular.

I've updated the status and we'll take this to the product team.
As a side note, it would be helpful for us if you could outline the gap between what ignored files offers, and what a .dropboxignore file feature would add to your workflows.

Thank you.

[l. jimmy]

+1

[Justin from Just Front-end]

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

-Stream com.dropbox.ignored, and whatnot. And yep, they don't work. Not as a long term fix.

And I admit, if Dropbox had the gitignore solution, it would have been nice, it would have solved our specific use case. And the feature would have made sense, as a nice to have.

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.

[nicc777]

@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.

[DelugeIA]

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

[mweirauch]

@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.

[ErwinM]

@mweirauch, you're a real life hero.

[mpbx1]

-- deleted --

[valentiger]

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.

[timfurnish]

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 !

[JaronFort]

We use Dropbox for continuous backup of full stack and mobile applications. Adding new projects (or sub-projects to existing projects) is a common task. Having to do this with selective-sync for each team member does not scale well and wastes precious time.

Having a `.dropboxignore` file would be a game changer because it would allow new projects in our workspace to be added without lengthy synchronization of "node_modules" directories which can grow quite large as our applications scale. A `.dropboxignore` file could rest inside the route of our workspace and all projects created within the workspace directory would have all "node_modules" folders automatically ignored by Dropbox. The `.dropboxignore` file can also be shared easily with new team members so that they do not accidentally upload `node_modules` to Dropbox.