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.

[Razvan Boxifier]

---

@Justin from Just Front-end wrote:

Are you by chance, able to explain exactly what this command is doing?

"Set-Content -Path C:\Users\yourName\Dropbox\someFolder -Stream com.dropbox.ignored -Value 1"

I read the Microsoft docs on "Set-Content", but I'm perplexed exactly on how this stops Dropbox from syncing?

---

---

---

Sure, what that command does is to mark a folder on the local filesystem so that it is ignored by the Dropbox sync engine. It does that by attaching an "alternate data stream" (which is a feature of the NTFS filesystem) to the folder that you want to exclude from syncing. You can think of it like putting a sticky note on a folder.

When scanning the Dropbox folder looking for changes to sync, Dropbox checks for the presence of such alternate data stream named  "com.dropbox.ignore" attached to a folder. What that PowerShell command that you quoted does is to attach an alternate data stream named "com.dropbox.ignore", with the contents of the stream being "1". In computer code, 1 is the value for "true" or "enabled".

This means that the decision to ignore the folder is only stored locally (on that computer), so it only applies to the computer where you run the command, not other computers where you are also using Dropbox with the same account.

@Justin from Just Front-end wrote:

Is there a list of files/folders somewhere on one's computer which Dropbox uses as a reference for
what files/folders not to sync?

Or is such a reference stored in the cloud?

To answer your question, there isn't one place or list on one's computer for Dropbox to use as a reference. It builds that list on-the-fly by scanning the Dropbox folder and seeing which folders have the ".com.dropbox.ignore" sticky note attached to them.

Hope that helps!

Razvan

[Justin from Just Front-end]

@Razvan Boxifier - Thank you so much!

What a great explanation. Much appreciated.

[sebastian_]

Hi @Razvan Boxifier, Thank you for the explanation.

Will this work when set on a root directory so that ALL `node_modules` sub-directories ever created now, or in the future, deleted, and re-created over time will be ignored and not synced without further user action? Each of these `node_module` cache folders contain hundreds of thousands of files each and undergo regular refreshes. It's absolutely critical that Dropbox NOT process/traverse these sub-directories whatsoever.

If `com.dropbox.ignore` can be set at the Dropbox/ root, will you explain the exact steps for macOS? It will be such a life saver.

[Vercjames]

I actively use dropbox to manage all my client projects. In addition to sorting all my client/project assets, each one has at least two github repository nested within. I did this because its an amazing user experience to have all my files, environment variables, and graphic assets sync seamlessly between 6 different workstations. The single bane of my existence is the node_modules folder. Any time I create a new project or start adding more dependencies to an exciting one - dropbox takes an eternity to sync do to this folder. Having to manually deselect every singe node_modules folder just isn't a sustainable approach. I think Dropbox could benefit from creating a .gitignore equivalent so I can remove certain folders or file types globally from the system. 

[ReginaldBull]

Same here! In Dev-Environment there are a lot of Temp, cached, whatever files you don't want to sync. A way to exclude those files/folders via patterns would be very helpful. 

@Dropbox-Team / @Emma: Don't forget!!!! - Developers are very often a multiplicator for other customers...

[Update]

OMG - I just saw in one of the other comments that there is already a .dbxignore-File for Backups!!! 
Please! give us this feature for Sync. This would be a massive argument for DropBox.

Another argument: Sometimes you have very critical files on your machine like certificates or password-Files.
You don't want them synced to Dropbox or to another machine.

[Razvan Boxifier]

@sebastian_  wrote:

Will this work when set on a root directory so that ALL `node_modules` sub-directories ever created now, or in the future, deleted, and re-created over time will be ignored and not synced without further user action? Each of these `node_module` cache folders contain hundreds of thousands of files each and undergo regular refreshes. It's absolutely critical that Dropbox NOT process/traverse these sub-directories whatsoever.

If `com.dropbox.ignore` can be set at the Dropbox/ root, will you explain the exact steps for macOS? It will be such a life saver

---

Unfortunately, setting 'com.dropbox.ignore' at the Dropbox/root would not achieve the desired effect, because that would mean asking Dropbox to ignore the entire contents of the Dropbox folder. That is due to the way the 'com.dropbox.ignore' feature is currently implemented in the Dropbox desktop client. For now it is only possible to ignore existing folders by marking them individually with 'com.dropbox.ignore'.

What you described makes perfect sense and I am thinking of another way to achieve that. I will write back here if I find something worth mentioning.

[DelugeIA]

This is currently the TOP VOTED IDEA and it is now over EIGHT YEARS OLD.

The Dropbox Development Team must be familiar with git, .gitignore, robots.txt, .htaccess, Mod_Rewrite, and a hundred other things that use regex and pattern matching to accomplish this task. It surely cannot be as complicated as examining NTFS's ADS tags.

It seems that a minimum solution would to be able to add an option to Right Click > Dropbox > Ignore this File/Folder. But having to do that over and over seems almost as tedious as running a Powershell command.

And for us nerds, being able to add an entry to dropbox.ini or somewhere to ignore all XYZ named folders within an ABC path.

Ignore_Matching %Dropbox%\Projects\**\.vscode

Ignore_Matching %Dropbox%\Projects\**\.pio

Ignore_Matching %Dropbox%\Testing\**\nightly-builds\*.zip

Ignore_Matching %Dropbox%\National\Archives\Mar-a-Lago\Classified\*.pdf

Thank ya! 🙂

[nicc777]

@DelugeIA- don't hold your breath 🙂

This feature appears to have completely beaten the dropbox techies.

[Justin from Just Front-end]

@Razvan Boxifier 

Here’s some thoughts.

The whole file/folder pattern based approach has merit, but in my opinion, I see some tradeoffs with this approach. The main issue I see, is that you’d be giving up the ability to actually have a folder named “node_modules”, that actually can be synced.

You should be able to have a folder named “node_modules”, have it be located anywhere within your projects or anywhere in Dropbox, have it be for actual real node modules, or have it be just some random folder, that happens to be named node_modules, even if, as bad of an idea that it is, you should be able to do this. You should be able to selectively decide what gets synced and what stays local only.

My idea, essentially, is just an enhancement to the mechanisms that we’re already working with, ie. the ADS.

Here’s my idea, at least for Windows:

• Any file/folder, anywhere, can be set to be local-only via a right click action. We’re simply giving a GUI experience for running the ADS on the file/folder.
  
• Upon setting the ADS on a file/folder, we update the file/folders icon in File Explorer.

And that’s it.

It’s worth mentioning also, as it is right now via ADS, if a file/folder is local-only, if it’s deleted, then recreated, it does NOT automatically get set as local only. This makes sense. (Highlighting how this would be different with pattern based rules.)

Also, here’s a few things I recently stumbled upon, that might help or spark ideas from the community:

• From what I understand, I think this is an approach to setting your node_modules to a location outside of your project, ie. a global place:
  https://docs.npmjs.com/cli/v8/commands/npm-prefix
• Here’s a client to see ADS’s (Update: I'm actually not sure what this streams thing is. Couldn't get it to work on Windows 11. Don't think it was what I thought it was.)
  https://learn.microsoft.com/en-us/sysinternals/downloads/streams

And last, if you or anyone is interested in collaborating on the development of this, here’s a repo I just made on Github. Connect with me if you wanted to contribute.

https://github.com/justfront-end/DB-Local-Only

[nicc777]

@Justin from Just Front-end 

---

The main issue I see, is that you’d be giving up the ability to actually have a folder named “node_modules”, that actually can be synced.

---

With regex you can be fairly explicit as to what you want to include and exclude. I don't see this as a major issue.

The point is a ".gitignore" style solution is not rocket science and I think at this point we are just generally disappointed in the lack of action/urgency from the dropbox business. Many technical users like me have moved on to alternatives. Right now I'm only still on this discussion to see if and when dropbox will ever listen to their community of users. It makes for a great case study.