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
