DropBox - "incorrect_offset"

[LizWatchesStuff]

I ran dedupe and it turns out only one folder contained dupes, unless there's something the command is missing?

I also downloaded a problem file from google drive to my PC (maxing out my gigabit line) without issue and I'm now uploading it to DropBox to see what happens.

EDIT: problem file did not upload, same issue. I am trying to rename it now to see if it works

[LizWatchesStuff]

@ncw

path/malformed_path/

malformed_path for uploading file into my dropbox

Some googling led me to this. It might be an issue with DropBox, is it possible a filename is too long?

Also the documentation mentions some things

Path formats

Paths are relative to an application's root (either an app folder or the root of a user's Dropbox, depending on the app's access type). The empty string ("") represents the root folder. All other paths must start with a slash (e.g. "/hello/world.txt"). Paths may not end with a slash or whitespace. For other path restrictions, refer to the help center.

Every file and folder in Dropbox also has an ID (e.g. "id:abc123xyz") that can be obtained from any endpoint that returns metadata. These IDs are case-sensitive, so they should always be stored with their case preserved, and always compared in a case-sensitive manner. Some endpoints, as noted in the individual endpoint documentation below, can accept IDs in addition to normal paths. A path relative to a folder's ID can be constructed by using a slash (e.g. "id:abc123xyz/hello.txt").

For endpoints that accept performing actions on behalf of a team administrator using the Dropbox-API-Select-Admin header, files may be referenced using a namespace-relative path (e.g. "ns:123456/cupcake.png"). In this case, the namespace ID, "123456", would be the shared_folder_id or team_folder_id of the shared folder or the team folder containing the file or folder, and the path, "/cupcake.png", would be the logical path to the content relative to its shared folder or team folder container.

Path case insensitivity

Like in Dropbox itself, paths in the Dropbox API are case-insensitive, meaning that /A/B/c.txt is the same file as /a/b/C.txt and is the same file as /a/B/c.txt.

This can cause problems for apps that store file metadata from users in case-sensitive databases (such as SQLite or Postgres). Case insensitive collations should be used when storing Dropbox path metadata in such databases. Alternatively, developers need to make sure their query operators are explicitly case insensitive.

Also, while Dropbox is case-insensitive, it makes efforts to be case-preserving. Metadata.name will contain the correct case. Metadata.path_display usually will contain the correct case, but sometimes only in the last path component. If your app needs the correct case for all path components, it can get it from the Metadata.name or last path component of each relevant Metadata.path_display entry.

[ncw (Nick Craig-Wood)]

@LizWatchesStuff

It might be an issue with DropBox, is it possible a filename is too long?

Yes it could be - that is a good idea.

According to my tests dropbox does give the error when you upload a too long path

2020/10/22 16:18:58 INFO  : Dropbox root 'test-length': Couldn't write file with name length 256: upload failed: path/malformed_path/..

Dropbox can only have 255 character path names.