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

DaphneAs jvasileff mentioned, this is awesome! Already putting it into action and taking it for a spin.

To build on their comment, I have a ton of projects that have a bunch of common folders like, "node_modules", "Pods", "vendor", "build", "public", etc. It's fairly challenging to have to manually go through all my projects and ignore those files.

Are there any plans to have a centralized place in the Dropbox app where we can add file patterns to ignore?

Thanks!

It is true that ignored folders will no longer appear in dropbox.com but substantial problems remain in place with this feature.

In particular, it seems that dropbox still monitors what happens inside ignored folders. When I have a "build" folder that is set to be ignored where thousand of files change suddenly, dropbox still tries to index and even sync all files, consuming a lot of system resources. 

This can easily be replicated. If I go inside the build folder that I ignored and create a simple .txt file, dropbox immediately starts indexing and syncing it. 

sebastian_ the fundamental problem here is that using xattr is a hacky solution that probably won't work in the long run, as the attributes are tied to a specific file or folder. Many developers have ephemeral node_modules or build folders that create new files/folders without extended attributes.

Dropbox changed their selective sync process which is a major step backwards. My laptop is running hot most of the time now with constant useless dropbox syncs. Previously all I had to do was uncheck folders like build, node_modules, temp, logs and others to ignore them. Now all that does is create selective sync conflicts. Grrrr!! :tired_face:

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

This feature is long overdue. It's not just a simple matter to "just put folders you want to ignore outside of dropbox".

It's very common when working in some types of projects (especially involving code) to want to avoid crufty temp files or machine generated files saving to the cloud, and at the same time, for the human created files to upload normally. 

This is why .gitignore is a thing.

Of course I use version control, and can do this outside of Dropbox, but I've found it's quite annoying when collaborating, and I have a perfect project folder to work out of, which has art assets and such under Dropbox, to then need to completely set up a separate duplicate project outside of the folder structure just to get Dropbox to ignore some folders.

> Dropbox team -- Pelase add a real .dropboxignore w/o reindexing

Ditto. Symbolic links are hacky workarounds with significant downsides, and the xattr approach has problems too.

But for the time being, for Java developers on macs, the code below can be added to `.gradle/init.gradle` to:

1. Automatically reconfigure build directories to directories within `~/Downloads/builds` using the default build directory as a template. So, for example, a gradle project `~/Dropbox/Projects/myproject` will build to `~/Downlods/Dropbox/Projects/myproject/build`.
2. Automatically create convenience symlinks as necessary. For example, after the build of `myproject`, the following symlink would be created: `~/Dropbox/Projects/myproject/build` -> `~/Downlods/Dropbox/Projects/myproject/build`

The idea is similar to the `node_modules` symlink workaround, but fully automated.

Code to add to `~/.gradle/init.gradle`:

import java.io.File
import java.nio.file.Files
import java.nio.file.LinkOption

def updateBuildPaths(p) {
    // change build dir to
    // ~/Downloads/builds/DEFAULT_BUILD_PATH_RELATIVE_TO_HOME
    def homePath = new File(System.env.HOME).toPath()
    def buildBasePath = homePath.resolve("Downloads/builds")
    def projectPath = p.projectDir.toPath()
    def relativeProjectPath = homePath.relativize(projectPath)

    p.ext.defaultBuildDir = projectPath.resolve("build")
    p.ext.newBuildDir = buildBasePath.resolve(relativeProjectPath)
            .resolve("build")

    p.buildDir = p.ext.newBuildDir

    // recurse into subprojects
    p.subprojects { s ->
        updateBuildPaths(s)
    }
}

def updateBuildDirSymlinks(p) {
    def defaultExists = Files.exists(
            p.ext.defaultBuildDir, LinkOption.NOFOLLOW_LINKS)

    def newExists = Files.exists(
            p.ext.newBuildDir, LinkOption.NOFOLLOW_LINKS)

    def linkExists = Files.isSymbolicLink(p.ext.defaultBuildDir) &&
            Files.readSymbolicLink(p.ext.defaultBuildDir) == p.ext.newBuildDir

    // add symlinks for build directory if possible & necessary
    if (!defaultExists && newExists) {
        Files.createSymbolicLink(p.ext.defaultBuildDir, p.ext.newBuildDir)
    }

    // print warning if pre-existing default build file or dir exists but is
    // not a link to the new build directory
    if (defaultExists && !linkExists) {
        println(
            "WARNING: unused default build directory exists at '" +
            "${p.ext.defaultBuildDir}'; please delete or link to " +
            "actual build directory '${p.ext.newBuildDir}'"
        )
    }

    // remove symlinks to non-existent build dirs
    if (!newExists && linkExists) {
        Files.delete(p.ext.defaultBuildDir)
    }

    // recurse into subprojects
    p.subprojects { s ->
        updateBuildDirSymlinks(s)
    }
}

gradle.projectsLoaded {
    updateBuildPaths(rootProject)
}

gradle.buildFinished {
    updateBuildDirSymlinks(rootProject)
}

Dropbox is being built by developers, and a simple (!) ignore for folders or files shoud not only be trivial, but really essential for developers. Just copy the darn sources from any SCC. On top of that, selective sync simply doesn't work reliably - I just had Dropbox mess with an "ignored" node_modules folder again. Srsly guys....

Just my 0.02$

this is a big headache please fix...

For anyone else who is sick of it and has the option, seafile handles this issue very elegantly. Wish I had made the change months ago.