search

memo33 / sc4pac-tools

Package manager for SC4
https://memo33.github.io/sc4pac/
GNU General Public License v3.0
9 stars 1 forks source link

Random failure on "channel build" command #6

Closed Zasco closed 1 month ago

Zasco commented 1 month ago

The "channel build" command fails randomly. Retrying it a few times solves it. Thought it was linked on not having the CLI window focused, but it sometimes still succeeds. Command is called from a batch file.

Last error message when it happened:

java.nio.file.DirectoryNotEmptyException: F:\Libraries\Programmes\Jeux\Maxis\SC4 Tools\sc4pac\channels\zasco\metadata\dk1\king-and-queen at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source) at java.nio.file.Files.deleteIfExists(Unknown Source) at os.remove$.apply(FileOps.scala:318) at os.remove$.apply(FileOps.scala:312) at os.remove$all$.apply$$anonfun$5(FileOps.scala:329) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10) at geny.Generator.foreach$$anonfun$1(Generator.scala:50) at geny.Generator$Mapped.generate$$anonfun$4(Generator.scala:283) at os.walk$stream$$anon$2$$anon$3.postVisitDirectory(ListOps.scala:271) at os.walk$stream$$anon$2$$anon$3.postVisitDirectory(ListOps.scala:265) at java.nio.file.Files.walkFileTree(Unknown Source) at os.walk$stream$$anon$2.generate(ListOps.scala:276) at geny.Generator$Mapped.generate(Generator.scala:283) at geny.Generator.foreach(Generator.scala:51) at geny.Generator.foreach$(Generator.scala:33) at geny.Generator$Mapped.foreach(Generator.scala:281) at os.remove$all$.apply(FileOps.scala:329) at os.move$over$.apply(FileOps.scala:129) at io.github.memo33.sc4pac.ChannelUtil$.processPackages$1$$anonfun$1(Cha nnelUtil.scala:183) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10) at zio.ZIOCompanionVersionSpecific.attempt$$anonfun$1(ZIOCompanionVersio nSpecific.scala:103) at zio.ZIO$.suspendSucceed$$anonfun$1(ZIO.scala:4638) at zio.UnsafeVersionSpecific.implicitFunctionIsFunction$$anonfun$1(Unsaf eVersionSpecific.scala:27) at zio.Unsafe$.unsafe(Unsafe.scala:37) at zio.ZIOCompanionVersionSpecific.succeed$$anonfun$1(ZIOCompanionVersio nSpecific.scala:185) at zio.internal.FiberRuntime.runLoop(FiberRuntime.scala:904) at zio.internal.FiberRuntime.runLoop(FiberRuntime.scala:890) at zio.internal.FiberRuntime.runLoop(FiberRuntime.scala:967) at zio.internal.FiberRuntime.evaluateEffect(FiberRuntime.scala:381) at zio.internal.FiberRuntime.evaluateMessageWhileSuspended(FiberRuntime. scala:504) at zio.internal.FiberRuntime.drainQueueOnCurrentThread(FiberRuntime.scal a:220) at zio.internal.FiberRuntime.run(FiberRuntime.scala:139) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Press any key to continue . . .

sc4pac version: 0.4.4

OS: Windows 8.1

Output of java -version:

java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b15) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b15, mixed mode)

memo33 commented 1 month ago

Does this happen with both 0.4.4 and 0.4.5?

memo33 commented 1 month ago

From the trace, it looks like this happens when you build the channel on top of a previously built channel. In my own scripts, I always delete the previously built files to remove any old data, so haven't encountered this so far.

Zasco commented 1 month ago

Does this happen with both 0.4.4 and 0.4.5?

Has not happened so far while using 0.4.5. Will follow up if it does.

Zasco commented 1 month ago

From the trace, it looks like this happens when you build the channel on top of a previously built channel. In my own scripts, I always delete the previously built files to remove any old data, so haven't encountered this so far.

Will try solution if ever happen again.

memo33 commented 1 month ago

I've studied the documentation for the APIs I use a bit. The function I use should already ensure that the old folder from previous runs of channel-build is properly deleted. This is known to fail occasionally for reasons outside sc4pac's control. For example, a file or folder might be locked as it's opened in another process, by another program.

There's not really anything I can do to avoid that, except for providing a better error message – and that's what I've just implemented.