AccessDeniedException when two resources have the same filename but different paths

[crt-31]

In my project's 'resources', I have two files with the same filename but different paths. They are both listed in the bloop config "resources" section. When I build, Bloop throws AccessDeniedException (see below).

This is likely due to change made in #1631 .

Ideally the resources would be put in their appropriate place in the 'classes' folder, then everything would work. But that would take some more specification in the bloop config, or mapping (#2592), or heuristics.

Below is the error I get... in bloop config I have listed in resources both a LowEnd\Quad.glsl and a HighEnd\Quad.glsl.

Unexpected error when copying \XXX\resources\LowEnd\Quad.glsl to .bloop\XXX\bloop-bsp-clients-classes\classes-Metals-EvCmu-WwSrOP6PClmtGf6A==\Quad.glsl, you might need to restart the build server.
java.nio.file.AccessDeniedException: .bloop\XXX\bloop-bsp-clients-classes\classes-Metals-EvCmu-WwSrOP6PClmtGf6A==\QuadPS.glsl
at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:171)
at java.base/sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:284)
at java.base/java.nio.file.Files.copy(Files.java:1305)
at bloop.io.ParallelOps$.copy$1(ParallelOps.scala:214)
at bloop.io.ParallelOps$.$anonfun$copyDirectories$10(ParallelOps.scala:251)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at monix.eval.internal.TaskRunLoop$.startFuture(TaskRunLoop.scala:494)
at monix.eval.Task.runToFutureOpt(Task.scala:586)
at monix.eval.internal.TaskDeprecated$Extensions.runSyncMaybeOptPrv(TaskDeprecated.scala:128)
at monix.eval.internal.TaskDeprecated$Extensions.$anonfun$coeval$1(TaskDeprecated.scala:303)
at monix.eval.Coeval$Always.apply(Coeval.scala:1451)
at monix.eval.Coeval.value(Coeval.scala:258)
at bloop.io.ParallelOps$.$anonfun$copyDirectories$9(ParallelOps.scala:279)
at monix.reactive.internal.consumers.ForeachAsyncConsumer$$anon$1.onNext(ForeachAsyncConsumer.scala:44)
at monix.reactive.internal.consumers.LoadBalanceConsumer$$anon$1.$anonfun$signalNext$1(LoadBalanceConsumer.scala:218)
at monix.execution.internal.InterceptRunnable.run(InterceptRunnable.scala:27)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)

[tgodzik]

Thanks for reporting! Does it happen all the time for you? We copy files to the same structure, but I noticed multiple times that there might be multiple threads trying to copy things, which shouldn't actually happen since we do lock files to only copy one time per target path.

[crt-31]

Well, all the resource files are being copied into the top level 'classes' path... they don't seem to be retaining any original structure. So the two entries would step on eachother.

In the bloop config, the files are each separate entries:

resources : [
   "C:\myproject\resources\LowEnd\Quad.glsl",
   "C:\myproject\resources\HighEnd\Quad.glsl",
]

Note, using bloop v2.0.8.

(probably different issue, but I'm noticing in some projects the resources are being copied to the classes dir, but on others they are not being copied at all. )

[tgodzik]

There is no way to preserve the structure if the files have the same name. You would have to include "C:\myproject\resources" instead. It's the same as with classpath, you would only have one of those files loaded from classpath.

So overall, having resources as files and same name can't really be done.

[crt-31]

So overall, having resources as files and same name can't really be done.

That is until we do (#2592). Can't wait :)

Regardless, it did break our builds which was not expected. We'll just have to not put in the resources into the config for now till #2592 is done, but then our test and run (that uses the file resources) won't work properly till then.