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

Same problem here, reinstall and update didn't solve anything.

Directly after excluding a folder and until the local deletion is complete, the command "exclude list" still shows those folders. After the operation is applied they are gone and there is no way to get them back.

Same problem here, reinstall and the update didn't solve anything. The only thing I've found that could reset my exclude list was removing the Dropbox application, the Dropbox daemon, and the nautilus extension.
When you add a folder to the exclude list, what dropbox seems to do, is to download that folder fully, and then delete it, and eventually, that folder's name will disappear from the exclude list out of no reason,,, even though it indeed is not being synced, and you can no longer sync that folder ever again without reinstalling the whole thing.

I'm a paying customer and contacted support. I informed them of this forum thread and the multiple users facing the same issue. I'll update everyone if I hear a resolution, but I hope Dropbox addresses the issue here.

UPDATE:

A couple weeks ago I got a reply back from Dropbox support saying:

"I've raised this with our engineering teams, and will be back in touch with any updates or information."

Well, 2 weeks later and still no update 😒

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

I tried a full reinstall (including removal of the entire Dropbox directory), and this time I didn't change any selective sync settings until the initial sync was finished, but I'm still having the same problem. I probably should have clarified that this is a relatively fresh and clean Ubuntu installation (of the latest LTS distro, compliant with the listed Dropbox requirements) and a totally fresh and clean "headless" Dropbox daemon installation (as of this afternoon an hour or two before I posted here):

```

$ cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -

[...]

$ wget https://www.dropbox.com/download?dl=packages/dropbox.py 

```

As I mentioned above, everything else seems to work, including the initial `dropbox.py exclude add <directory>`. It's worth noting that on my earlier installation `dropbox.py exclude` did show excluded directories until the daemon finished removing them; I tried to reproduce this after the second install, but this time I think the daemon was faster than me since it wasn't busy with sync tasks.

Since the last nautilus-dropbox release (of which the Python CLI script is a part) was over a year ago, I was wondering if some more recent change in the daemon might have broken compatibility, so I tried talking to the daemon's command socket directly using the "protocol" documented by the open-source CLI code. I was able to reproduce the same bad (or at least unexpected) behavior without running the CLI at all.

First, check the status of an existing, synced directory (with a file in it):

```

<redacted>@<redacted>:~/.dropbox$ nc -U command_socket
icon_overlay_file_status
path    /home/<redacted>/Dropbox/test_dir_3
done
ok
status up to date
done

```

(Everything up to and including the first "done" is my input; the rest is the response from the socket, with the first line ("ok" in this case) being the overall response status.)

Next, add that directory to the ignore set:

```

ignore_set_add
paths   /home/<redacted>/Dropbox/test_dir_3
done
ok
ignored /home/<redacted>/Dropbox/test_dir_3
unrecognized
done

```

The "ok" status is a good sign, and the "ignored" line indicates that the directory has been added to the ignore set. However, the daemon claims the ignore set is still empty:

```

get_ignore_set
done
ok
ignore_set
done

```

But the directory has been removed:

```

icon_overlay_file_status
path /home/<redacted>/Dropbox/test_dir_3
done
notok
The 'path' argument does not exist
done

 ```

`ls` in the shell confirms the same.

The command socket obviously isn't an officially documented API (confirmed by your team here), but all I'm doing here is imitating the commands the Python CLI sends to it. The socket is accepting these commands and giving sensible responses that match what I get when I use the CLI to do the same things (and don't return any error statuses), so my guess is that this is a bug in the daemon. A permissions or other configuration problem seems unlikely given that all the other features I've tested are working fine.