Problems with handling spaces in file/directory names #229
Assignees
Comments
|
It appears MantaUtils.formatPath method is using The following shows a series of tests I did with curl: In the output, you can see that creating directories with spaces in the path makes manta unhappy. But plus symbols are indeed stored as plus symbols, while %20 chars are stored as spaces. |
cburroughs
added a commit
to cburroughs/java-manta
that referenced
this issue
Apr 21, 2017
When Manta paths appear as part of the of a url (which they do on most api requests), reserved characters must be encoded just like in any other url. Paths were encoded inconsistently (in that they were sometimes encoded, sometimes not, and sometimes encoded twice). When paths were encoded, spaces were not encoded correctly (turned to `+`) because despite the tantalizing name `java.net.URLEncoder` does does not encode strings for inclusion in a url. The contract for `MantaObject.getPath` has been clarified. It should always return the "real" (un-encoded) path. ref TritonDataCenter#229 TritonDataCenter#230 231
cburroughs
added a commit
to cburroughs/java-manta
that referenced
this issue
Apr 21, 2017
When Manta paths appear as part of the of a url (which they do on most api requests), reserved characters must be encoded just like in any other url. Paths were encoded inconsistently (in that they were sometimes encoded, sometimes not, and sometimes encoded twice). When paths were encoded, spaces were not encoded correctly (turned to `+`) because despite the tantalizing name `java.net.URLEncoder` does does not encode strings for inclusion in a url. The contract for `MantaObject.getPath` has been clarified. It should always return the "real" (un-encoded) path. ref TritonDataCenter#229 TritonDataCenter#230 TritonDataCenter#231
cburroughs
added a commit
to cburroughs/java-manta
that referenced
this issue
Apr 24, 2017
When Manta paths appear as part of the of a url (which they do on most api requests), reserved characters must be encoded just like in any other url. Paths were encoded inconsistently (in that they were sometimes encoded, sometimes not, and sometimes encoded twice). When paths were encoded, spaces were not encoded correctly (turned to `+`) because despite the tantalizing name `java.net.URLEncoder` does does not encode strings for inclusion in a url. The contract for `MantaObject.getPath` has been clarified. It should always return the "real" (un-encoded) path. ref TritonDataCenter#229 TritonDataCenter#230 TritonDataCenter#231
cburroughs
added a commit
that referenced
this issue
Apr 24, 2017
When Manta paths appear as part of the of a url (which they do on most api requests), reserved characters must be encoded just like in any other url. Paths were encoded inconsistently (in that they were sometimes encoded, sometimes not, and sometimes encoded twice). When paths were encoded, spaces were not encoded correctly (turned to `+`) because despite the tantalizing name `java.net.URLEncoder` does does not encode strings for inclusion in a url. The contract for `MantaObject.getPath` has been clarified. It should always return the "real" (un-encoded) path. ref #229 #230 #231
|
Thank you for the detailed report. In |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have files and directory stored in manta that actually have spaces. It seems node-manta tools allow this (I populated the directories with
muntar). The node-manta toolsmlsandmfindproperly list the files with spaces too:Unfortunately, the java-manta client seems to return these paths with spaces replaced by plus symbols. Trying to request one of these paths then fails as the path doesn't actually exist with plus sybols... it exists with spaces.
The solution isn't as simple as
URLEncode.encode(path, 'UTF8')either since that will replace the path separators with %2F.The text was updated successfully, but these errors were encountered: