SDK doesn't handle Unicode control characters.

[jicoop]

Basically I have a code that does this:

    private final DbxUserFilesRequests files;

    @SneakyThrows
    public Metadata getMetadata(String path) {
        return files.getMetadata(path);
    }

This works for normal paths that don't contain control characters.

However, if you supply path that contains the Unicode Control Characters that aren't escaped:

/SomeFolder/acces
s_token.txt

It spits out this issue:

 java.lang.IllegalArgumentException: String 'path' does not match pattern
    at com.dropbox.core.v2.files.GetMetadataArg.<init>(GetMetadataArg.java:58)
    at com.dropbox.core.v2.files.GetMetadataArg.<init>(GetMetadataArg.java:80)
    at com.dropbox.core.v2.files.DbxUserFilesRequests.getMetadata(DbxUserFilesRequests.java:1602)

But if you escape the path from unicode characters like this:

acces\u2028s_token.txt

It seems that the library escapes the backslash character, and causes the API to return the Malformed path response.

    "error": {
        ".tag": "path",
        "path": {
            ".tag": "malformed_path"
        }
    }

Unfortunately, I don't really have a choice in renaming the file. Is there a solution we can have to handle the unicode control? Like another method that allows us to supply a string that won't be processed by the SDK?

I know from cURL, it's possible to use the escaped form of the unicode character and get the metadata. However, it's just not a choice I have from the java SDK since it won't do it for me, and it doesn't like the escaped version of unicode.

[greg-db]

Thanks for the detailed post. It looks like this may just be a bug in the Java SDK. I'll ask the team to look into it.

[devPalacio]

I filed an issue with the stone repo, since the regex we're currently using is what is causing the IllegalArgumentException in our generated code.