The filestore dir is where the packages live. If we move it to another location, existing installations might fail. So, it's a backward incompatible change.
What are our options? Is it possible to have these directories precreated in the distro/code to ensure that these warnings don't come. On Thu, Sep 3, 2020, 4:58 AM Erick Erickson <erickerick...@gmail.com> wrote: > Oh bother. Somehow I thought I’d looked and only a handful of tests > reported this. > > So I looked again and I _wish_ I was able to blame drugs cause you’re > right, there > are over a thousand of them. > > Never mind... > > > On Sep 1, 2020, at 8:55 PM, Chris Hostetter <hossman_luc...@fucit.org> > wrote: > > > > > > : Hmmm, that’s kind of an dilemma then. Are you saying that > > : he test can see that the directory appears writable then tries > > : to write to it then gets tripped up by the framework? > > : > > : Seems to me that a test that tries to write, thinks it can and then > > : can’t should fail anyway. > > : > > : Well, I don’t think there are very many tests that have this problem > > : anyway, so maybe I can examine them one-by-one and not > > : introduce new failures... > > > > You keep using the phrase "the test" in the context of (trying to) > create > > these directories ("userfiles" and "filestore") ... the "test CODE" > isn't > > making any choices about trying to write those files -- the choice is > > being made by the "CoreContainer CODE". > > > > These features were added with the explicit implementation choice to > _TRY_ > > to write the "usersfiles" (and/or "filestore") directory to "solr home" > IF > > POSSIBLE, and if so then enable a bunch of features -- if NOT then log a > > WARNing and don't enable those features. > > > > So what you're seeing here isn't an artifact/result of any particular > > choices "a test" or "the test" makes -- it's a concious choice of the > > developer who added this feature to solr. These WARN messages that show > > up in tests where the solr home dir isn't writable (which is actaully > the > > vast majority of tests because of how the test framework works) are the > > same types of WARN messages that a "real" solr deployment might get if > > their solr home dir isn't wriable (ie: maybe the use ${solr.data.dir} to > > point to a diff drive). > > > > > > > > : > > : > On Aug 31, 2020, at 1:29 PM, Chris Hostetter < > hossman_luc...@fucit.org> wrote: > > : > > > : > > > : > Some tests "create" a new solr home dir and copy config files there, > but > > : > you'll see this type of WARN logging for any test that just uses the > test > > : > configs "in place" because of how the code is designed to _try_ and > create > > : > a userfiles directory in the solr home if it's writable. > > : > > > : > > > : > : Date: Sat, 29 Aug 2020 09:25:17 -0400 > > : > : From: Erick Erickson <erickerick...@gmail.com> > > : > : Reply-To: dev@lucene.apache.org > > : > : To: dev@lucene.apache.org > > : > : Subject: Re: Annoying but harmless exceptions due to > filepermissions when > > : > : running tests > > : > : > > : > : Well, as Uwe and I discussed offline, he’s right and I’m wrong. > > : > : > > : > : In CoreContainer [364] there’s code like this: > > : > : > > : > : Path userFilesPath = return solrHome.resolve("userfiles"); // TODO > make configurable on cfg? > > : > : try { > > : > : Files.createDirectories(userFilesPath); // does nothing if > already exists > > : > : } catch (Exception e) { > > : > : log.warn("Unable to create [{}]. Features requiring this > directory may fail.", userFilesPath, e); > > : > : } > > : > : > > : > : So I assumed it would happen on most every test, at least in cloud > mode. But when I tried to make it happen on a different test, there was no > exception. > > : > : > > : > : I’ll have to poke some more to see what’s really happening… > > : > : > > : > : Never Mind…. > > : > : > > : > : > On Aug 29, 2020, at 8:59 AM, Uwe Schindler <u...@thetaphi.de> > wrote: > > : > : > > > : > : > Hi, > > : > : > > > : > : > this is a bug in the test! It should never ever modify files > outside its sandbox. It should not even modify files in build directory. It > is fully valid to reject those writes - has nothing to do with users, it's > just forbidden by the test framework. Modifying this file is harmful, as it > may affect later tests. > > : > : > > > : > : > So the correct way is to copy those files to the solr container > running inside test's sandbox. That's one of the main advantages of the > Test sandbox: No write access anywhere outside the test, see policy file. > > : > : > > > : > : > Uwe > > : > : > > > : > : > ----- > > : > : > Uwe Schindler > > : > : > Achterdiek 19, D-28357 Bremen > > : > : > https://www.thetaphi.de > > : > : > eMail: u...@thetaphi.de > > : > : > > > : > : >> -----Original Message----- > > : > : >> From: Erick Erickson <erickerick...@gmail.com> > > : > : >> Sent: Saturday, August 29, 2020 2:54 PM > > : > : >> To: dev@lucene.apache.org > > : > : >> Subject: Annoying but harmless exceptions due to > filepermissions when running > > : > : >> tests > > : > : >> > > : > : >> These exceptions are handled in the code and don’t affect > running tests, but > > : > : >> they can be a distraction when trying to figure out what’s > causing a failure. > > : > : >> When CoreContainer is being initialized, these two paths get > “Permission > > : > : >> Denied” errors since they try to create directories/files. > > : > : >> > > : > : >> java.security.AccessControlException: access denied > ("java.io.FilePermission" > > : > : >> > "/Users/Erick/apache/solrJiras/master/solr/core/build/resources/test/solr/filest > > : > : >> ore" "write”) > > : > : >> > > : > : >> java.security.AccessControlException: access denied > ("java.io.FilePermission" > > : > : >> > "/Users/Erick/apache/solrJiras/master/solr/core/build/resources/test/solr/userf > > : > : >> iles" "write”) > > : > : >> > > : > : >> In both cases, the code logs a warning like "Features requiring > this directory > > : > : >> may fail”. > > : > : >> > > : > : >> “build” is permitted this way, so I guess gradle runs as some > other user? > > : > : >> > > : > : >> drwxr-xr-x 11 Erick staff 352 Aug 28 09:30 build > > : > : >> > > : > : >> Any hints on an easy way to avoid these? It’s not worth much > effort I don’t > > : > : >> think since they’re handled, but if it’s easy I’d like to not > see them. > > : > : >> > > : > : >> > > : > : >> > > : > : >> > --------------------------------------------------------------------- > > : > : >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > : > : >> For additional commands, e-mail: dev-h...@lucene.apache.org > > : > : > > > : > : > > > : > : > > --------------------------------------------------------------------- > > : > : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > : > : > For additional commands, e-mail: dev-h...@lucene.apache.org > > : > : > > > : > : > > : > : > > : > : > --------------------------------------------------------------------- > > : > : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > : > : For additional commands, e-mail: dev-h...@lucene.apache.org > > : > : > > : > : > > : > > > : > -Hoss > > : > http://www.lucidworks.com/ > > : > > > : > --------------------------------------------------------------------- > > : > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > : > For additional commands, e-mail: dev-h...@lucene.apache.org > > : > > : > > : --------------------------------------------------------------------- > > : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > : For additional commands, e-mail: dev-h...@lucene.apache.org > > : > > : > > > > -Hoss > > http://www.lucidworks.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >