[jira] [Comment Edited] (SOLR-9444) Fix path usage for cloud backup/restore

["Uwe Schindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439185#comment-15439185 ] 

Uwe Schindler edited comment on SOLR-9444 at 8/26/16 2:54 PM:
--------------------------------------------------------------

I'd suggest do let the first parameter of the createURI abstract method take URI (as basis URI), and then the String Path components. Then you can remove all code that just calls URI.getPath() to (incorrectly) to extract the path filesystem path (or whatever path) from the URI, misusing escaping. If you are Using the URI class from the begijning, use it everywhere.

For pathes that *might be file system pathes* (without an URI protocol), the config file parsing code should have a fallback catch clause like - or maybe using a regex that checks for a missing protocol (I assume the latter might be better):
{code:java}
final URI uri;
try {
 uri = new URI(stringFromConfigFile);
 // a bit of hack:
 if (!uri.isAbsolute)) throw new URiSyntaxException("use fallback");
} catch (URISyntaxException use) {
 uri = Paths.get(stringFromConfigFile).toURI();
}
{code}

And this can be safely passes around. If you want to use this later and extend with other relative stuff (e.g. in createURI abstract method), use the above baseURI and append the other string parameters with "resove". In general this could be done completely unspecific to the file system impl (outside repository impl classes).

Inside FileSystemRepository you can then use {{Paths.get(URI)}} to convert it to a file system instance (that would then even work with Java's native ZIPFS or others: [https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html#get-java.net.URI-])


was (Author: thetaphi):
I'd suggest do let the first parameter of the createURI abstract method take URI (as basis URI), and then the String Path components. Then you can remove all code that just calls URI.getPath() to (incorrectly) to extract the path filesystem path (or whatever path) from the URI, misusing escaping. If you are Using the URI class from the begijning, use it everywhere.

For pathes that *might be file system pathes* (without an URI protocol), the config file parsing code should have a fallback catch clause like:
{code:java}
final URI uri;
try {
 uri = new URI(stringFromConfigFile);
} catch (URISyntaxException use) {
 uri = Paths.get(stringFromConfigFile).toURI();
}
{code}

And this can be safely passes around. If you want to use this later and extend with other relative stuff (e.g. in createURI abstract method), use the above baseURI and append the other string parameters with "resove". In general this could be done completely unspecific to the file system impl (outside repository impl classes).

Inside FileSystemRepository you can then use {{Paths.get(URI)}} to convert it to a file system instance (that would then even work with Java's native ZIPFS or others: [https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html#get-java.net.URI-])

> Fix path usage for cloud backup/restore
> ---------------------------------------
>
>                 Key: SOLR-9444
>                 URL: https://issues.apache.org/jira/browse/SOLR-9444
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Varun Thacker
>
> As noted by Uwe on https://issues.apache.org/jira/browse/SOLR-9242?focusedCommentId=15438925&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15438925 the usage of URI#getPath is wrong. 
> Creating a Jira to track this better. More details to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org