Add .dropboxignore directory to exclude folders without using selective sync

DelugeIA I've been actively monitoring every response in this thread for 10 years and have on multiple times raised alarms when they try closing this discussion to rile people up to make them reopen it. I cannot for the life of me understand how the most requested feature EVER, which isn't even that complex, has been unaddressed for 10 years. 

I will grant you that right clicking and telling Dropbox to not sync a folder works fine for most users and most cases.

My problem, and seemingly the problem that others are facing, is that if you have to do this for EVERY instance where you don't want material to be copied. There is no way to say don't ever sync a "build" folder, or a "temp" folder, or a ".git" folder, or a "my_secret_stash_of_pron" folder. You must first create the folder and then tell Dropbox to ignore it.

When I create a new project in Visual Studio Code, I want most of it backed up! I want Dropbox to actively record my changes to my source, libraries, and configurations. I want Dropbox to help serve as an immediate backup between saves. I want Dropbox to make it so that I can pick up an active project from another machine. These are all great things!

But every project that I start or do work on, I have to remember to go in and exclude certain folders every time. If I forget, I will inevitably run into problems when Dropbox has a (very brief) lock on a file and thus ACTIVELY INTERFERES with the build process where dozens/hundreds of temporary files are created and destroyed. I will get inevitably get an error message that XYZ files cannot be removed or is locked by another process. The same with Git, when I'm moving between branches or committing changes, Dropbox will try to sync all the tiny changes that happen to hundreds/thousands of tiny files in the object .git/objects directory.

I cannot fathom how the Dropbox developers themselves don't understand this need?!
I just want to be able to configure a single file, or even go in and set a preference that is able to use wildcard characters:

C/Users/imsolazy/Dropbox/**/.git
C/Users/imsolazy/Dropbox/**/.build
C/Users/imsolazy/Dropbox/Project/*/.vscode
C/Users/imsolazy/Dropbox/Project/*/tmp
C/Users/imsolazy/Dropbox/Project/*/vendor

This way when I create a new project, I'm confident that Dropbox is backing up my important stuff but isn't causing undue problems.

Respectfully submitted to the void,

-- Jeff Sorensen

A new user in our lab just set up our Dropbox repo on their computer, but did not follow the proper order of things to get it working with a local folder within the Dropbox directory. The order being:
(1) sync with current state of the Dropbox,
(2) turn off sync,
(3) make the new folder that will be ignored,
(4) issue the command to ignore that folder,
(5) turn on sync.
The local folder is used to store specific settings and files to their local setup, that differs for each computer/user/setup. We are running script, from within the Dropbox directory, that needs to know where that local folder is. The main idea of keeping it within the Dropbox directory was to reduce setup steps the user has to do to get everything working. However, because the user did not follow the order of operations needed to be done above (they skipped step 2), the local folder created "Item Conflict" folders in every user's setup and effectively corrupted all of them. Now we need to go through and clean this up for every user/computer.

The user-side solution to this is to pull the local folder out of the Dropbox directory and require users to point to their local folder when setting up their environment. This adds a step that we were trying to mitigate though, which would be easily fixed with an .ignore file -- so that every user that sets up their environment automatically has this local directory available to them (and the script knows exactly where it is) after syncing Dropbox, without needing to create new folders and pointing to it or otherwise adding additional steps. When we develop repositories with GitHub, the .gitignore file accomplishes this for us by ignoring all wild cards within that local folder. I hope this shows a use case for this, like Emma asked for. It's not a needed feature, but a very useful one. I think there is a lot of confusion going around in this thread, and I hope this clears some of it up and shows a specific use case where it is beneficial. That's it, thanks for listening. 

projectdeliverypartnersLike I said - if it works for you great - it's not the solution that works for the rest of us.

I think everything we do is probably very similar, we work on files on a computer and often not in the same location as our colleagues. We don’t want Dropbox syncing certain files within a certain folder for whatever reason. Its not hard, and from reading this thread i doubt any of you have tried this at all yet your saying it doesn’t work. Emma summed it up beautifully, what would a .Dropbox placeholder do that the don’t sync feature doesn’t?  Or another way to put it, what other cloud based solutions of this dollar level do what you’re asking? I don’t reckon any of them come close. Google kind of has something but it’s a mess. 
I got it working with a placeholder as the trigger anyway, if I tidied it up and triple checked everything would you use it cause that would be a little bit of work, not heaps but ya know 

projectdeliverypartners- as mentioned now several times by several people, it is not really ideal for many other types of workflows or use cases. It may work for you and your use case, so then that is fine. However, this is not the solution we are seeking.

Also, some feedback from dropbox is desperately needed as this idea is hitting it's 10 year anniversary.

It's there in a simple right click context menu. It works on both platforms. it's scriptable. Given it can be triggered, that means something can also trigger it (a trigger trigger) and this is how your ignore files could work but how thats better than the right click or double click a shortcut I don't know. 

If your work is project based, and you don';t want it to upload/sync until your done and out of the project, this works really well. two ways I've done it are
1 - right click the project folder and 'don't sync to dropbox', do your work save exit and then right click on the project folder and choose 'sync to dropbox'.

2 - use the code for Mac and PC I posted earlier and save a powershell/Mac script and you can set a global trigger to run that code, on the parent folder, of any project opened by app x. This is what I do at the moment, I only had to set up the code once, nothing has to be pasted around the place etc, I just carry on working as if nothing is any different and it works great.

This is a great example that if you don't want to build something, then just be transparent about it. Not let people vote, give them false hope to then continue ignoring them on the highest voted idea. I can't explain it anymore with being not clear, nor having not enough interest.

This is turning 10 years in two months, maybe some anniversary party though? 😅

Nancyor BenDBX    Reaching out as it seems no one at dropbox is taking this idea serious. At the moment there are numerous hacks and workarounds, but I think it would still be great if dropbox can consider a final solution for this idea.

Can we at least just get some feedback from dropbox or get an explanation about what the actual issue is with this solution taking so long?

Personally I have not used dropbox in a while because of this missing feature and the hacks does not always work everywhere (or with mixed results), but I would really not mind starting to use it again if this can be resolved.

EmmaTwo years have passed, are there any survey results for this feature?