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

[jvasileff]

@Daphne that's great news! I look forward to trying it out.

But it would also be nice to have a configuration file, like ".dropboxignore", to list paths or patterns to exclude. The reason is that extended attributes are tied to the actual file or folder, and will be gone if the file or folder is deleted and recreated.

The common use case for this is a software build folder that gets deleted and recreated on clean builds. Under xattr system, the "new" build folder would sync to Dropbox even if the "old" build folder had the necessary com.dropbox.ignored xattr.

[jvasileff]

> 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)
}

[sebastian_]

@jvasileff, Nice contribution and I like your automation improvement for java development.

[hardcodet]

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$

[totesmagotes]

This. A thousand times this. I'm a developer, and my project will constantly generate loads of temporary data that doesn't need to be synced across dropbox. I don't even understand why selective sync doesn't work like this to begin with. If all I wanted was to delete the folder, I'd delete the folder myself. Selective sync is useless the way it works now.

[VPEN]

Yes please, come on devs, you are devs too, I know you understand the need for this, just get the message through to the pointy haired bosses ; )

.dropboxignore (folder specific)
.dropboxigonreglobal (in dropbox root folder)

[ccd1]

this is a big headache please fix...

[Daphne]

Hello everyone, I hope you're all doing well!

I just wanted to ping you all as I've moved your feedback on this feature here, so that we can better keep track of all your comments.

I've passed this all along to our devs for them to review, so thank you for taking the time to share your thoughts and experience on using this feature so far.

The feature is still in beta, so the team is still working on this. Your feedback is therefore very important to us so please keep it coming!

Just for reference too, the thread you all initially posted in is here. You should still all be subscribed there, just mentioning the thread as an FYI if needed.

If you need anything, please give me a nudge here and I'd be happy to help.

Have a great day ahead!

[adamL]

I'm now doing all web development outside of my Dropbox folder, and have an rsync script watching my web dev folder to copy files BACK into the Dropbox folder (ignoring node_modules and other files I don't want clogging up my Dropbox account and resources). And I know this is not a solution that will work for everyone especially considering it takes up extra space on my hard drive. But that's what I've had to resort to, adding to the many other war stories on this thread.

I use Selective Sync to offload big files to Dropbox, which works fine, except it completely removes the folder from my local computer. I would completely forget the folder is there because I don't see it (I'm aware I could be using the "Smart Sync" feature, but I do not like it ... it can be a disaster if you have to copy files over to a new hard drive).

Therefore when I use Selective Sync, I usually create a folder locally with the same name as the one I just offloaded, thus creating a folder on my computer with the "little gray minus icon". Which tells me that "this folder is on Dropbox".

With the new ignore feature, things are a bit more complex. My new process is:

• Make folder
• Move big files into folder
• Uncheck folder via selective sync and wait for process to complete
• Create folder with same name
• Dropbox will rename folder with (Selective Sync Conflict)
• Do terminal command:  xattr -w com.dropbox.ignored 1 /Volumes/Storage/Dropbox/. . . /Your Folder Name
• Rename local folder with same name as remote folder

Not sure if this makes any sense at all, but this is my experience, and obviously it could be less complex. In any case, not sure why we're beating around the bush with long stories such as mine. Other people have already offered a decent solution for situation:

Dropbox needs a way to globally and locally ignore files. And if something gets ignored, it LITERALLY gets ignored ... Removed from remote Dropbox. No folder renaming. No syncing. No indexing. Dropbox leaves it on the local computer and walks away.

[mixmonkey]

Hi all, just gave the beta ignore feature a try. All it seems to do is put a little grey icon on my file.

If I create a file with the same name in the same folder on another machine, I get an '(Ignored Item Conflict)' on the first machine. I thought the whole point was that files set to ignore didn't sync...

[maku77]

We want gitignore-like solution, not a command that needs a specific path.