.mignore file causes sync error due to new Dropbox business folder structure

[DaGaMs]

Describe the bug

Dropbox recently changed how folders are organised for business accounts. The top-level directory in the dropbox root directory is not writeable to the user any more, but instead contains sub-folders for the various groups you're a member of, and a folder with your full name as a "private" space.

Now, when I put the .mignore file in the top-level directory, I always get this error message in the maestral log:

2023-11-10 20:53:04 sync INFO: Could not sync .mignore
Traceback (most recent call last):
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/errorhandling.py", line 90, in convert_api_errors
    yield
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/client.py", line 923, in _upload_helper
    md = self.dbx.files_upload(
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/dropbox/base.py", line 3210, in files_upload
    r = self.request(
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/dropbox/dropbox_client.py", line 351, in request
    raise ApiError(res.request_id,
dropbox.exceptions.ApiError: ApiError('f83b74a47e3a471ab4de5b2cf0122231', UploadError('path', UploadWriteFailed(reason=WriteError('no_write_permission', None), upload_session_id='pid_upload_session:ABIHCmsQXv3-yUSYqyde1axtA0vxhu_k-PA026FXyvpq14ZYsA')))

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/sync.py", line 2311, in _create_remote_entry
    status = self._on_local_file_modified(event)
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/sync.py", line 2490, in _on_local_file_modified
    md_new = self.client.upload(
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/client.py", line 870, in upload
    res = self._upload_helper(
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/client.py", line 331, in wrapper
    return func(__self, *args, **kwargs)
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/client.py", line 923, in _upload_helper
    md = self.dbx.files_upload(
  File "/opt/gridware/depots/1a8f5697/el7/pkg/apps/python3/3.8.1/gcc-4.8.5/lib/python3.8/contextlib.py", line 131, in __exit__
    self.gen.throw(type, value, traceback)
  File "/users/bschuster/gridware/share/python/3.8.1/lib/python3.8/site-packages/maestral/errorhandling.py", line 92, in convert_api_errors
    raise dropbox_to_maestral_error(exc, dbx_path, local_path)
maestral.exceptions.InsufficientPermissionsError: Could not upload file. You do not have permissions to write to the target location.

System:

• Maestral version: 1.8.0
• Python version: 3.8.1
• OS: [e.g. Ubuntu] Debian
• Desktop environment: [e.g. Gnome 3.32] na
• PyQt version (for Linux GUI): na

Additional context

[samschott]

Thanks for the report! Darn it, this sounds like it will be a bit of a pain to adapt to.

Are all of the sub-folders still synching correctly in this new model?

[DaGaMs]

I think so. But I only installed maestral after the migration to the new (forced) folder structure, so it did a clean sync from scratch and all seems ok.

I am having an issue where, after adding a fairly large amount of data all at once, maestral now is stuck on syncing, ie files are queued but no uploads are happening. However, I very much doubt this has anything to do with this issue. More likely some indexing issue, or maybe I ran into some API limits (no idea how to find out).

[samschott]

More likely some indexing issue, or maybe I ran into some API limits (no idea how to find out).

This may well be API limits. You can check the logs for "backoff" of "ratelimit" messages after increasing the log level to DEBUG with maestral log level DEBUG. No need to restart Maestral for this, log level changes take effect immediately.

[DaGaMs]

No backoff or ratelimit messages. All I get is a few successful API calls, and then an infinite sequence of Request to files/upload_session/append_v2:

2023-11-11 11:01:12 sync INFO: Syncing ↑ 173/573
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/upload_session/append_v2
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/get_metadata
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/upload_session/append_v2
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/upload_session/append_v2
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/upload_session/append_v2
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/upload_session/append_v2
2023-11-11 11:01:13 dropbox_client DEBUG: Request to files/upload_session/append_v2
2023-11-11 11:01:14 dropbox_client DEBUG: Request to files/upload_session/append_v2
[...]

However no syncing happens, it seems to make these API calls and wait for a response over and over again.

Last night, I also tried a re-indexing. This morning I saw this message:

✓ Sync is not running. Rebuilding scheduled for next startup.

Presumably the same issue/some sort of timeout? I stopped/started the daemon again, then I get the above behaviour with the very many append_V2 calls.