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.

[Walter]

Hey @caconym, thanks for using Dropbox and welcome aboard!

Since the app isn't behaving well when it comes to selective sync through the CLI, could you try re-installing it and let me know if it improved matters?

Regarding the option to auto-start the app, note that this command may only work on currently supported Ubuntu distributions.

Keep me posted with your results!

[caconym]

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.

[Walter]

Thanks for keeping me in the loop on this one and sorry for the late reply @caconym.

If you're still having issues with this, may I reach out via email to investigate a bit further?

[jwvjwvjwv]

I'm also experiencing this exact same issue (and have been for the last couple months) on Fedora 34. Someone else has posted about it on stackoverflow as well. The only thing I've found that could reset my exclude list was removing the Dropbox application, the Dropbox daemon, and the nautilus extension. After reinstalling, all of my folders sync again, but once I exclude any of them again, I can't un-exclude them without uninstalling and reinstalling everything again.

[caconym]

Hey Walter, sorry I didn't see this until now. I'm happy to discuss the issue over email, DM, or whatever else.

[SGuo]

I can confirm, the exclude is useless at this point, the behavior is so random and this is so frustrating. 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. Who invented this mechanism? He/she single-handedly wasted all these resources of network and time of ours.

[linux000001]

BUMP

I installed from source and experience the same issue.

@Walter...a DM doesn't help anyone else on this forum...you got some ideas share them.

[cvmls]

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.

[drkivid]

Same problem here.