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.

[sebastian_]

@cabreu, There seems to be a bug in the community forum itself. Their support team is working on it...

[JimRobinson]

This has been a problem for many years, why is there no .dropboxignore?   I don't see how setting a file attribute helps as the folders most developers care about get deleted and re-created may times a day, for example node_modules or "build" folders with compiled artifacts.    I'm interested to see @Sebastian s suggestion when the problem with the link is fixed.

[sebastian_]

@JimRobinson @cabreu I've reposted the ignore node_modules solution as the first version is stuck with technical support working on a fix. Hopefully this new re-post is accessible. (It currently comes up for me in incognito mode, so it should work.)

How to make Dropbox ignore node_modules folder with symbolic links (aliases) 

The post is specifically written for use for Javascript / TypeScript Node development as the node_modules folder is massive and shouldn't be sync'd with the cloud storage. Each machine will have its own "non-sync'd" instance via symlink in the ~/Downloads folder.

NOTE: This same technique can be used to ignore other folder types with drag-n-drop aliases.

[sebastian_]

Indeed! Excited here too about the new ignore attribute! As mentioned in the Ignore with Symlinks post, there is an upside and a downside to each approach. The xattr method works perfectly by not pushing content to the cloud, HOWEVER, upon EVERY change within node_modules, Dropbox reindexes it triggering a long-running processor load which delays other legitimate uploads outside that folder. I don’t know why Dropbox is doing this, unless the it allows re-including deeper content, but wish it "truly ignored" the entire directory. The symlink method avoids reindexing entirely, so there is zero-impact when changes occur. If xattr ignore could be configured to truly ignore and not reindex, then it would be perfect for all requirements.

Is anybody else with early access to xattr ignore seeing reindexing on folders with > 50K files? To test it, after applying each ignore method (xattr ignore, and symlink ignore), delete “all contents" of the node_modules folder (not the node_modules folder itself!!), then `yarn install` and watch Dropbox behavior + processor load. How long does it take for Dropbox to return to idle?

• The SymLink Ignore method can be found, HERE
• The Xattr Ignore method can be found, HERE

[dkobia]

@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!! 

[jvasileff]

> My laptop is running hot most of the time now

That's really the biggest problem - syncing build folders destroy battery life. My workaround is to pause the sync, but that creates a mess if I forget to re-enable when I'm done with my work.

> Many developers have ephemeral node_modules or build folders that create new files/folders without extended attributes

Yes.

[nickyhajal]

Yep - I am also finding these exact issues with the existing proposed solution.

Why can't I just give the Dropbox indexer patterns to ignore?! Exactly the way Megasync, pCloud, etc. make possible; this doesn't seem like rocket science.

Even if it is more complicated than I imagine, surely it is much simpler than many of the other technical feats Dropbox has accomplished in the past.

[Alexander_V]

You can perform MITM attack on Dropbox process an hijack requests to read and write to HDD. Basically I think it's possible to create own wrapper HDD driver that will provide "per-process" controll of what visible/writable. Maybe looking into open-source NTFS implementation will give a hint. Anyway I'm always lazy in doing such stuff but maybe somebody has a good programmer friend who could research on that idea.

[Alexander_V]

Another way is to sandbox Dropbox process somehow into tiny thin *nix wrap and marshal only filtered requests to the host os.

[sebastian_]

@dkobia, I agree xattr is not ideal for node_modules as it's currently implemented. It made my processor run hot all the time due to reindexing with every change. I am using symlinks (aliases) at this time and it works perfectly across systems with no processor load impact. I would truly appreciate a .dropboxignore file that ignores targets, just like .gitignore (a hard-ignore, no reindexing whatsoever).

I posted this above, but will link it again as the symlink ignore method works like a charm for node_modules: SymLink Ignore Method

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