Can't un-exclude directories with `dropbox.py exclude remove <directory>` on Ubuntu 20.04.2

[caconym]

I have a Linux machine (running Ubuntu 20.04.2 LTS, "Focal Fossa") upon which I am running a "headless" Dropbox daemon as per here: https://www.dropbox.com/install-linux

The Dropbox daemon is up to date:

```

$ dropbox.py version
Dropbox daemon version: 125.4.3474
Dropbox command-line interface version: 2020.03.04

```

This machine is truly "headless", so I am doing everything on the command line. Installation of the daemon and initial sync seemed to work fine, though autostart isn't working for me.

I've found that I can exclude directories with `dropbox.py exclude add <directory>` just fine. When I run that command for a directory in my Dropbox, the directory briefly appears in the list output from `dropbox.py exclude`. However, once the directory is actually deleted from the local Dropbox directory, it disappears from the list too. For example, I do have a bunch of directories excluded, and they are not present in the local Dropbox directory. However, the tool incorrectly reports no excluded directories:

```

$ dropbox.py exclude
No directories are being ignored.

```

This is fine, if a bit weird, but the problem is that I can't add excluded directories back (un-exclude them?) with `dropbox.py exclude remove <directory>`. That command outputs nothing and has no effect.

Why not? How can I get this to work? It seems totally broken right now.

[sarke]

Same issue here, very frustrating.  We've been paying Business Team account for almost a decade.

@caconym, do you (or anyone else) know what the correct syntax is for ignore_set_remove on the command socket? Specifically the paths argument, is there a certain array/list format?

ignore_set_remove
paths   /opt/dropbox/Dropbox/somefolder
done
ok
removed
unrecognized    /opt/dropbox/Dropbox/somefolder
done

EDIT: So the paths are tab separated. ignore_set_add seems to work but not ignore_set_add.

[sarke]

Reverting to 123.4.4832 fixes the problem.  It seems 124.4.4912 introduced the bug.

[lassamaria]

Thank you sarke! Reverting to 123.4.4832 fixed it for me. It's sad that Dropbox won't fix the bug they introduced at that point, but at least old versions are still available. No idea what new features were added after that version but they don't seem to be worth this serious bug.

[iqvoice]

I also have this problem.  Would be nice to see a fix.

[alanpaulkwan]

How does one revert back to 123.4.4832?

Edit: This is a bit of a band-aid solution, but a workaround to this problem is just to use the GUI from Linux. However, I surmise Dropbox crashes on GUIs that don't support the Dropbox icon in the system tray (e.g. whatever the jazzy Ubuntu 20 default is) but works fine on XCFE.

So I launched a VNC session, which on my machine defaults to xcfe (which is compatible). And the GUI permits you full visibility into your folders.

[HallwaySail]

I'm having the same issue:

```

Dropbox daemon version: 132.4.3800

Dropbox command-line interface version: 2020.03.04

```

I've followed the advanced reinstall instructions and even tried setting up a new machine with the same result every time. This is having a major ongoing impact on our business.

[jwvjwvjwv]

I got fed up waiting for anything to come of this thread and contacted Dropbox support (which maybe I should have done all along... I thought they monitored the forums). This will probably get resolved sooner if more of us contact support: https://www.dropbox.com/support/email

[jwvjwvjwv]

Update from support: Lucky us! We're low priority!

---

October 14, 2021, 10:12 AM PDT:
We have received a word back from the engineers and they have informed that this is a known issue which is currently being investigated by their team.
It has been set to low priority from the team so it may take a while for it to be fixed. We apologise for any inconvenience.

---

[linux000001]

It's literally the only thing I can observe that is broken! Otherwise, Dropbox is working as expected. Now I'm sure there's other fish to fry, but how does something that is so obvious get pushed to "low priority"? It's like driving w/ a flat tire...sure you'll get from A to B but boy would it be better if you had a new stereo system!

[JuhaPalomaki]

Funny - I was just last week wondering how I had managed to setup the selective sync on one of my Linux machines without using the exclusion list. As the list was empty, I was assuming it was not in use.

Now I hit the problem on another machine as well.  The main problem is that this also seems to make it impossible to remove folders form the exclusion lists. 

I'm a bit surprised this kind of regression is labeled as "low priority". This file syncing stuff is kind of key feature of the product. Re-installation etc. are not a cool workaround when you have some hundreds of thousands of files.