Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-9444

Fix path usage for cloud backup/restore

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.2
    • Fix Version/s: 6.2.1, 6.3, 7.0
    • Component/s: None
    • Security Level: Public (Default Security Level. Issues are Public)
    • Labels:
      None

      Description

      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

      1. SOLR-9444.patch
        26 kB
        Uwe Schindler
      2. SOLR-9444.patch
        4 kB
        Varun Thacker

        Issue Links

          Activity

          Hide
          hgadre Hrishikesh Gadre added a comment -

          Varun Thacker Thanks for creating the JIRA. I will send out a patch later today.

          Show
          hgadre Hrishikesh Gadre added a comment - Varun Thacker Thanks for creating the JIRA. I will send out a patch later today.
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          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):

          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();
          }
          

          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-)

          Show
          thetaphi Uwe Schindler added a comment - - edited 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): 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(); } 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- )
          Hide
          varunthacker Varun Thacker added a comment -

          Quick patch which uses Paths.get() instead of URI.getPath.

          TestHdfsBackupRestoreCore will fail because with:

          
          39668 ERROR (OverseerThreadFactory-10-thread-3-processing-n:127.0.0.1:60156_solr) [n:127.0.0.1:60156_solr    ] o.a.s.c.OverseerCollectionMessageHandler Collection: hdfsbackuprestore operation: backup failed:java.nio.file.FileSystemNotFoundException: Provider "hdfs" not installed
          	at java.nio.file.Paths.get(Paths.java:147)
          	at org.apache.solr.cloud.BackupCmd.call(BackupCmd.java:98)
          	at org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:222)
          	at org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463)
          	at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$26(ExecutorUtil.java:229)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
          	at java.lang.Thread.run(Thread.java:745)
          

          I think thats related to https://github.com/damiencarol/jsr203-hadoop

          Show
          varunthacker Varun Thacker added a comment - Quick patch which uses Paths.get() instead of URI.getPath. TestHdfsBackupRestoreCore will fail because with: 39668 ERROR (OverseerThreadFactory-10-thread-3-processing-n:127.0.0.1:60156_solr) [n:127.0.0.1:60156_solr ] o.a.s.c.OverseerCollectionMessageHandler Collection: hdfsbackuprestore operation: backup failed:java.nio.file.FileSystemNotFoundException: Provider "hdfs" not installed at java.nio.file.Paths.get(Paths.java:147) at org.apache.solr.cloud.BackupCmd.call(BackupCmd.java:98) at org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:222) at org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$26(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang. Thread .run( Thread .java:745) I think thats related to https://github.com/damiencarol/jsr203-hadoop
          Hide
          varunthacker Varun Thacker added a comment -

          I'm going to take a look at this

          Show
          varunthacker Varun Thacker added a comment - I'm going to take a look at this
          Hide
          thetaphi Uwe Schindler added a comment -

          I think the file system repository should only be used if the "protocol" is "file".

          Show
          thetaphi Uwe Schindler added a comment - I think the file system repository should only be used if the "protocol" is "file".
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          Quick patch which uses Paths.get() instead of URI.getPath.

          The issue lies deeper in the API design of the backup infrastructure: see my above comment! If you use URI, then use it completely and avoid any conversion between strings and URIs. This is almost always a bug.

          As said before only accept strings when parsing config files, in any other case just pass URI class around. If you really need to convert to String (e.g. when it goes over wire), convert with URI.toAsciiString() and decrypt with new URI(...).

          The choose of the repository provider should then be done soley on URI#getScheme(). Only use java.nio.Path in FileSystemRepsitory but not for URI schemes where there is a better alternative (e.g. Hadoop, Zookeeper).

          Show
          thetaphi Uwe Schindler added a comment - - edited Quick patch which uses Paths.get() instead of URI.getPath. The issue lies deeper in the API design of the backup infrastructure: see my above comment! If you use URI, then use it completely and avoid any conversion between strings and URIs. This is almost always a bug. As said before only accept strings when parsing config files, in any other case just pass URI class around. If you really need to convert to String (e.g. when it goes over wire), convert with URI.toAsciiString() and decrypt with new URI(...). The choose of the repository provider should then be done soley on URI#getScheme(). Only use java.nio.Path in FileSystemRepsitory but not for URI schemes where there is a better alternative (e.g. Hadoop, Zookeeper).
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user hgadre opened a pull request:

          https://github.com/apache/lucene-solr/pull/74

          SOLR-9444 Fix path usage for cloud backup/restore

          • Refactored code using URI.getPath() API to use URI instance
            uniformly.
          • During serialization of URI instance, used toASCIIString() API
            to generate the appropriate String representation.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/hgadre/lucene-solr SOLR-9444_fix

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/lucene-solr/pull/74.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #74


          commit 0acb659eacd7a7e6b76a2796bc9e75d5a815b439
          Author: Hrishikesh Gadre <hgadre@cloudera.com>
          Date: 2016-08-28T21:48:24Z

          SOLR-9444 Fix path usage for cloud backup/restore

          • Refactored code using URI.getPath() API to use URI instance
            uniformly.
          • During serialization of URI instance, used toASCIIString() API
            to generate the appropriate String representation.

          Show
          githubbot ASF GitHub Bot added a comment - GitHub user hgadre opened a pull request: https://github.com/apache/lucene-solr/pull/74 SOLR-9444 Fix path usage for cloud backup/restore Refactored code using URI.getPath() API to use URI instance uniformly. During serialization of URI instance, used toASCIIString() API to generate the appropriate String representation. You can merge this pull request into a Git repository by running: $ git pull https://github.com/hgadre/lucene-solr SOLR-9444 _fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/74.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #74 commit 0acb659eacd7a7e6b76a2796bc9e75d5a815b439 Author: Hrishikesh Gadre <hgadre@cloudera.com> Date: 2016-08-28T21:48:24Z SOLR-9444 Fix path usage for cloud backup/restore Refactored code using URI.getPath() API to use URI instance uniformly. During serialization of URI instance, used toASCIIString() API to generate the appropriate String representation.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Varun Thacker Uwe Schindler Could you please review the PR ? I have tested on Linux as well as Windows...

          Show
          hgadre Hrishikesh Gadre added a comment - Varun Thacker Uwe Schindler Could you please review the PR ? I have tested on Linux as well as Windows...
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user uschindler commented on a diff in the pull request:

          https://github.com/apache/lucene-solr/pull/74#discussion_r76740913

          — Diff: solr/core/src/java/org/apache/solr/core/backup/repository/LocalFileSystemRepository.java —
          @@ -58,21 +59,28 @@ public void init(NamedList args) {
          }

          @Override

          • public URI createURI(String... pathComponents) {
          • Preconditions.checkArgument(pathComponents.length > 0);
            -
          • String basePath = Preconditions.checkNotNull(pathComponents[0]);
          • // Note the URI.getPath() invocation on Windows platform generates an invalid URI.
          • // Refer to http://stackoverflow.com/questions/9834776/java-nio-file-path-issue
          • // Since the caller may have used this method to generate the string representation
          • // for the pathComponents, we implement a work-around specifically for Windows platform
          • // to remove the leading '/' character.
          • if (Constants.WINDOWS) {
          • basePath = basePath.replaceFirst("^/(.:/)", "$1");
            + public URI createURI(String location) {
            + Preconditions.checkNotNull(location);
            +
            + URI result = null;
            + try {
              • End diff –

          Nice. This is exactly as I proposed. So people can use both URIs with a file: or just a plain path. URI.isAbsolute() returns false, if scheme ("file:") is missing: <https://docs.oracle.com/javase/7/docs/api/java/net/URI.html#isAbsolute()> "A URI is absolute if, and only if, it has a scheme component."

          Show
          githubbot ASF GitHub Bot added a comment - Github user uschindler commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/74#discussion_r76740913 — Diff: solr/core/src/java/org/apache/solr/core/backup/repository/LocalFileSystemRepository.java — @@ -58,21 +59,28 @@ public void init(NamedList args) { } @Override public URI createURI(String... pathComponents) { Preconditions.checkArgument(pathComponents.length > 0); - String basePath = Preconditions.checkNotNull(pathComponents [0] ); // Note the URI.getPath() invocation on Windows platform generates an invalid URI. // Refer to http://stackoverflow.com/questions/9834776/java-nio-file-path-issue // Since the caller may have used this method to generate the string representation // for the pathComponents, we implement a work-around specifically for Windows platform // to remove the leading '/' character. if (Constants.WINDOWS) { basePath = basePath.replaceFirst("^/(.:/)", "$1"); + public URI createURI(String location) { + Preconditions.checkNotNull(location); + + URI result = null; + try { End diff – Nice. This is exactly as I proposed. So people can use both URIs with a file: or just a plain path. URI.isAbsolute() returns false, if scheme ("file:") is missing: < https://docs.oracle.com/javase/7/docs/api/java/net/URI.html#isAbsolute( )> "A URI is absolute if, and only if, it has a scheme component."
          Hide
          thetaphi Uwe Schindler added a comment -

          Hi,
          this looks cool! I will try it out in a minute on my windows with whitespace in path.
          This looks exactly as I proposed:

          • Only pass URI instances around instead of strings
          • Change createURI to take the base URI as URI
          • Add a new createURI that takes a single string and is responsible to create aplain RI from a string, which is repository specific

          Maybe rename the createURI that takes a baseURI and componenets to have a different name? E.g. resolveURI?

          Show
          thetaphi Uwe Schindler added a comment - Hi, this looks cool! I will try it out in a minute on my windows with whitespace in path. This looks exactly as I proposed: Only pass URI instances around instead of strings Change createURI to take the base URI as URI Add a new createURI that takes a single string and is responsible to create aplain RI from a string, which is repository specific Maybe rename the createURI that takes a baseURI and componenets to have a different name? E.g. resolveURI?
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          In the future, once the HDFS people created a working filesystem for Java 7, we may remove the HDFS special case, but for now its good to have. FYI: Using this new impl, it should be possible to create a backup in a zip file using the ZIP file system of Java 7+: http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html (see second example)

          Show
          thetaphi Uwe Schindler added a comment - - edited In the future, once the HDFS people created a working filesystem for Java 7, we may remove the HDFS special case, but for now its good to have. FYI: Using this new impl, it should be possible to create a backup in a zip file using the ZIP file system of Java 7+: http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html (see second example)
          Hide
          varunthacker Varun Thacker added a comment -

          will try it out in a minute on my windows with whitespace in path.

          I was thinking of maybe adding this as part of TestLocalFSCloudBackupRestore#getBackupLocation also?

          Show
          varunthacker Varun Thacker added a comment - will try it out in a minute on my windows with whitespace in path. I was thinking of maybe adding this as part of TestLocalFSCloudBackupRestore#getBackupLocation also?
          Hide
          thetaphi Uwe Schindler added a comment -

          Hi,
          to me this looks fine. I agree, adding a separate test for the local fs that tests both variants to use the path (as URI or plain path) should be added, too.
          On Windows with whitespace in file names I see no errors.

          It is currently only that some unrelated tests fail all the time, because Noble Paul broke Hadoop on Windows. In general Jenkins is very unstable on master, no successful runs since days.

          Show
          thetaphi Uwe Schindler added a comment - Hi, to me this looks fine. I agree, adding a separate test for the local fs that tests both variants to use the path (as URI or plain path) should be added, too. On Windows with whitespace in file names I see no errors. It is currently only that some unrelated tests fail all the time, because Noble Paul broke Hadoop on Windows. In general Jenkins is very unstable on master, no successful runs since days.
          Hide
          noble.paul Noble Paul added a comment -

          Which ticket exactly?

          Show
          noble.paul Noble Paul added a comment - Which ticket exactly?
          Hide
          thetaphi Uwe Schindler added a comment -

          SOLR-9460, not sure which one caused this. But you made changes on the failing test!

          Show
          thetaphi Uwe Schindler added a comment - SOLR-9460 , not sure which one caused this. But you made changes on the failing test!
          Hide
          thetaphi Uwe Schindler added a comment -

          SOLR-9460, not sure which one caused this. But you made changes on the failing test!

          Show
          thetaphi Uwe Schindler added a comment - SOLR-9460 , not sure which one caused this. But you made changes on the failing test!
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Uwe Schindler Varun Thacker Thanks for the reviews! Let me update the patch with following changes

          • Rename createURI(URI...) method to resolveURI(...)
          • Add a test for verifying the whites-paces in the backup location
          Show
          hgadre Hrishikesh Gadre added a comment - Uwe Schindler Varun Thacker Thanks for the reviews! Let me update the patch with following changes Rename createURI(URI...) method to resolveURI(...) Add a test for verifying the whites-paces in the backup location
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Varun Thacker Uwe Schindler I have updated the PR with above mentioned changes. Please take a look.

          Show
          hgadre Hrishikesh Gadre added a comment - Varun Thacker Uwe Schindler I have updated the PR with above mentioned changes. Please take a look.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user uschindler commented on a diff in the pull request:

          https://github.com/apache/lucene-solr/pull/74#discussion_r77301896

          — Diff: solr/core/src/test/org/apache/solr/cloud/TestLocalFSCloudBackupRestore.java —
          @@ -24,12 +24,20 @@

          • such file-system would be exposed via local file-system API.
            */
            public class TestLocalFSCloudBackupRestore extends AbstractCloudBackupRestoreTestCase {
            + private static String backupLocation;

          @BeforeClass
          public static void setupClass() throws Exception {
          configureCluster(NUM_SHARDS)// nodes
          .addConfig("conf1", TEST_PATH().resolve("configsets").resolve("cloud-minimal").resolve("conf"))
          .configure();
          +
          + boolean whitespacesInPath = random().nextBoolean();
          + if (whitespacesInPath) {
          + backupLocation = createTempDir("my backup").toFile().getAbsolutePath();
          — End diff –

          I'd use `backupLocation = createTempDir(...).toAbsolutePath().toString();` to get rid of legacy `java.io.File`

          Show
          githubbot ASF GitHub Bot added a comment - Github user uschindler commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/74#discussion_r77301896 — Diff: solr/core/src/test/org/apache/solr/cloud/TestLocalFSCloudBackupRestore.java — @@ -24,12 +24,20 @@ such file-system would be exposed via local file-system API. */ public class TestLocalFSCloudBackupRestore extends AbstractCloudBackupRestoreTestCase { + private static String backupLocation; @BeforeClass public static void setupClass() throws Exception { configureCluster(NUM_SHARDS)// nodes .addConfig("conf1", TEST_PATH().resolve("configsets").resolve("cloud-minimal").resolve("conf")) .configure(); + + boolean whitespacesInPath = random().nextBoolean(); + if (whitespacesInPath) { + backupLocation = createTempDir("my backup").toFile().getAbsolutePath(); — End diff – I'd use `backupLocation = createTempDir(...).toAbsolutePath().toString();` to get rid of legacy `java.io.File`
          Hide
          thetaphi Uwe Schindler added a comment - - edited

          Hi, looks fine to me! I can merge this later today. Varun Thacker?

          Show
          thetaphi Uwe Schindler added a comment - - edited Hi, looks fine to me! I can merge this later today. Varun Thacker ?
          Hide
          varunthacker Varun Thacker added a comment -

          Hi Uwe,

          Would you be committing this?

          Show
          varunthacker Varun Thacker added a comment - Hi Uwe, Would you be committing this?
          Hide
          thetaphi Uwe Schindler added a comment -

          OK!

          Show
          thetaphi Uwe Schindler added a comment - OK!
          Hide
          thetaphi Uwe Schindler added a comment -

          Here is the final patch. Committing now!

          Show
          thetaphi Uwe Schindler added a comment - Here is the final patch. Committing now!
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit e138462a82800be3811017062868051c14e560e6 in lucene-solr's branch refs/heads/master from Hrishikesh Gadre
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e138462 ]

          SOLR-9444 Fix path usage for cloud backup/restore

          • Refactored code using URI.getPath() API to use URI instance
            uniformly.
          • During serialization of URI instance, used toASCIIString() API
            to generate the appropriate String representation.
          • Updated the unit test to use whitespaces in the backup directory path
          Show
          jira-bot ASF subversion and git services added a comment - Commit e138462a82800be3811017062868051c14e560e6 in lucene-solr's branch refs/heads/master from Hrishikesh Gadre [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e138462 ] SOLR-9444 Fix path usage for cloud backup/restore Refactored code using URI.getPath() API to use URI instance uniformly. During serialization of URI instance, used toASCIIString() API to generate the appropriate String representation. Updated the unit test to use whitespaces in the backup directory path
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit d9c0f2c6b91bd97d7e17a0b6abf16cb9d0f71b52 in lucene-solr's branch refs/heads/master from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9c0f2c ]

          SOLR-9444: Fix path usage for cloud backup/restore
          Merge branch 'SOLR-9444_fix' of https://github.com/hgadre/lucene-solr
          This closes #74

          Show
          jira-bot ASF subversion and git services added a comment - Commit d9c0f2c6b91bd97d7e17a0b6abf16cb9d0f71b52 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9c0f2c ] SOLR-9444 : Fix path usage for cloud backup/restore Merge branch ' SOLR-9444 _fix' of https://github.com/hgadre/lucene-solr This closes #74
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit d9c0f2c6b91bd97d7e17a0b6abf16cb9d0f71b52 in lucene-solr's branch refs/heads/master from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9c0f2c ]

          SOLR-9444: Fix path usage for cloud backup/restore
          Merge branch 'SOLR-9444_fix' of https://github.com/hgadre/lucene-solr
          This closes #74

          Show
          jira-bot ASF subversion and git services added a comment - Commit d9c0f2c6b91bd97d7e17a0b6abf16cb9d0f71b52 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9c0f2c ] SOLR-9444 : Fix path usage for cloud backup/restore Merge branch ' SOLR-9444 _fix' of https://github.com/hgadre/lucene-solr This closes #74
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user asfgit closed the pull request at:

          https://github.com/apache/lucene-solr/pull/74

          Show
          githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/74
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 83479443783e73e073362c35eb7e3ab3885be6a6 in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8347944 ]

          SOLR-9444: Fix path usage for cloud backup/restore
          Merge branch 'SOLR-9444_fix' of https://github.com/hgadre/lucene-solr
          This closes #74

          Show
          jira-bot ASF subversion and git services added a comment - Commit 83479443783e73e073362c35eb7e3ab3885be6a6 in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8347944 ] SOLR-9444 : Fix path usage for cloud backup/restore Merge branch ' SOLR-9444 _fix' of https://github.com/hgadre/lucene-solr This closes #74
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 83479443783e73e073362c35eb7e3ab3885be6a6 in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8347944 ]

          SOLR-9444: Fix path usage for cloud backup/restore
          Merge branch 'SOLR-9444_fix' of https://github.com/hgadre/lucene-solr
          This closes #74

          Show
          jira-bot ASF subversion and git services added a comment - Commit 83479443783e73e073362c35eb7e3ab3885be6a6 in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8347944 ] SOLR-9444 : Fix path usage for cloud backup/restore Merge branch ' SOLR-9444 _fix' of https://github.com/hgadre/lucene-solr This closes #74
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          Re-opened to back-port to 6.2.1

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - Re-opened to back-port to 6.2.1
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9d3a2a0879be200cc3e4a4e3c2aa0f705ee08c12 in lucene-solr's branch refs/heads/branch_6_2 from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d3a2a0 ]

          SOLR-9444: Fix path usage for cloud backup/restore
          Merge branch 'SOLR-9444_fix' of https://github.com/hgadre/lucene-solr
          This closes #74

          (cherry picked from commit 8347944)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9d3a2a0879be200cc3e4a4e3c2aa0f705ee08c12 in lucene-solr's branch refs/heads/branch_6_2 from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d3a2a0 ] SOLR-9444 : Fix path usage for cloud backup/restore Merge branch ' SOLR-9444 _fix' of https://github.com/hgadre/lucene-solr This closes #74 (cherry picked from commit 8347944)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9d3a2a0879be200cc3e4a4e3c2aa0f705ee08c12 in lucene-solr's branch refs/heads/branch_6_2 from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d3a2a0 ]

          SOLR-9444: Fix path usage for cloud backup/restore
          Merge branch 'SOLR-9444_fix' of https://github.com/hgadre/lucene-solr
          This closes #74

          (cherry picked from commit 8347944)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9d3a2a0879be200cc3e4a4e3c2aa0f705ee08c12 in lucene-solr's branch refs/heads/branch_6_2 from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d3a2a0 ] SOLR-9444 : Fix path usage for cloud backup/restore Merge branch ' SOLR-9444 _fix' of https://github.com/hgadre/lucene-solr This closes #74 (cherry picked from commit 8347944)
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          Closing after 6.2.1 release

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - Closing after 6.2.1 release

            People

            • Assignee:
              thetaphi Uwe Schindler
              Reporter:
              varunthacker Varun Thacker
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development