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