Feedback on the new desktop app "ignore files" feature.

Thank you so much XionicFire... saves me the hassle of migrating to a new service, for the time being... unbelievable that dropbox is so useless on this issue that we have to resort to user posted .reg changes.

@Daphne Okay, XionicFire was right, I was simply having an issue because my paths had square brackets `[]`  in them and I needed to use `-LiteralPath` instead of `-Path`. 

However, even after ignoring the folders I wanted to ignore, Dropbox is still deciding to index them on every change and is locking file access when doing so, which is causing me lots of problems.

Dropbox shouldn't be accessing the files inside of an ignored folder at all. Also, Dropbox didn't used to lock file access when indexing/syncing, what changed? 

Yes i ran into the same problem with dropbox using ( ) in the name for the business dropbox, on my main servers i solved this problem by saving one of my old dropbox installation files that had my dropbox set to D:\Dropbox before they made the forced change, i then created a directory called Dropbox (W) and removed permissions so dropbox cant touch it, this way I have my dropbox still as D:\Dropbox which does not break all my scripts, not the most elegant solution but its the only way i found to keep my dropbox as Dropbox and not break my scripts.

Thanks for the suggestion i will update the code.

ccd1 , another user suggested a good change, ive updated the REG code to include it, it adds support for directories or files containing [ or ] characters, in case you want to update it to the new version, installing the update should be as simple as copying the new code and running the reg again.

Im glad its useful to people, I know id be going mad and killing someone if I didnt have this and I had to manually type every file/folder I need to ignore with random generated names all over the drive on 172 machines.

For those using Unity, here is an editor script I made to automatically set the ignore attribute on startup:

using System.Diagnostics;
using UnityEngine;
using UnityEditor;

[InitializeOnLoad]
public class EditorStartup
{
    //to make sure Temp folder doesn't get synced to Dropbox. Make sure Temp is deleted on Dropbox online
    //Temp folder gets deleted by Unity so the extended attributes need to be set every time
    static EditorStartup()
    {
        //when recompiling scripts this will get called again. check to make sure we only do this on actual editor start
        if (EditorApplication.timeSinceStartup > 60) return;
        //UnityEngine.Debug.Log("Editor startup script");
#if UNITY_EDITOR
        if (Application.platform == RuntimePlatform.OSXEditor)
        {
            Process.Start("xattr", "-w com.dropbox.ignored 1 Temp");
            UnityEngine.Debug.Log("xattr -w com.dropbox.ignored 1 Temp");
        }
        else if (Application.platform == RuntimePlatform.WindowsEditor)
        {
            Process.Start("PowerShell", "Set-Content -Path Temp -Stream com.dropbox.ignored -Value 1");
            UnityEngine.Debug.Log("PowerShell Set-Content -Path Temp -Stream com.dropbox.ignored -Value 1");
        }
#endif
    }
}

Yes, this simply needs to be a file which can be dropped into the root folder of your project called `.dbignore` which behaves in the same way as a `.gitignore` or a '.dockerignore' file in that the files are ignored for sync.

This would be so helpful when developing a project and not wanting package files or virtual environment files to be synced.

I can't tell you the number of times that I have had to log in to dropbox.com to delete all of the instances of `_______(Selective Sync Conflict)` folders from my project.

It also means that so many more files than is necessary is synced which takes uncessary syncing time.

This surely cannot be that hard to implement.

I've had a conversation with a Dropbox developer about them porting stuff to Rust. Between the lines he said that implementing ignoring files by setting the file attribute was the least amount of work of getting this implementing. This seemed to indicate that Dropbox still hasn't thought this through from the perspective of the user. I hope this will be revisited, because the current functionality is clumsy. If you delete a file from Dropbox, the attributes are gone. If a tool re-creates the file, you can start all over. We need an ignore file. Now.

The Powershell hack is completely broken, at least for developers. You just go to another machine and create that ignored folder (e.g. by building), and you're in a world of pain again.

Still can't understand that developers themselves wouldn't just add the .ignore file option as the initial and trivial solution. Gotta be honest: next time I'm taking on a software development project where I use Dropbox along with Git, I'm off to the competition...