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
