The PID for which I really need the command line arguments is the one which owns the file handle. That seems to be neither of those.
It’s essentially to collect all of this information immediately after having the problem.
it is, when you close the edit you were on, and open another edit of the same module. the one associated with this new edit is 5780
I don’t follow. Would you state clearly, after having the error, which PID is holding the file handle for a file mentioned in the error message, and what the command line args are for that PID? (Note that the PIDs are valid only in the context of a single run. If you do another run the PIDs will very likely have changed.)
PID handling ID is 5780
||Memory (private working set)
||C:\Program Files\VASSAL-3.6.2\jre\bin\java -Xms512M -Xmx512M -Duser.home=C:\Users\Scott -Duser.dir=C:\Program Files\VASSAL-3.6.2 -cp lib\Vengine.jar VASSAL.launch.Editor --edit – C:\Users\Scott\Vassal Modules\The Longest Day v 0.8.2.1.vmod
||OpenJDK Platform binary
There are no other PID sharing 5780
So, it can be the case that the process which is unable to move the file is the only one that has a file handle, and it’s blocking itself. The error message is misleading in that case, but nonetheless “another process” could be the same process.
That said, knowing that the editor process is the one holding the file open is about the least informative result we could have gotten. I had been hoping we would find it was a different process that was holding the file open.
What we’re left with is that the bug is either in Windows, Java, Vassal, or custom code in the module. The last can be eliminated due to there being no custom code in this module. Of the other three, Windows and Java we can do nothing about.
Do you have a scenario open at the same time as you’re trying to save the module?
I am sorry J No not a scenario only the module editor. But having the task manager and the other trace programs running that is how I can say the second file generates no Handles, As I Said before other mods will save under their own old name, Could this be something in the mod I have created? I can change the save name and it will work. (Save as) That is what I am left with for any minor updates.
Try saving the module without a scenario open. What happens?
Edited above. error reading what you said on my part.
In my opinion it is partially Win 8.1 and partially the Module, Since I built the module beginning with 3.6.0beta7 through 3.6.2 on Mint cinnamon 18.3 using java 17. I would bet it is the mod, something inside is not playing nice with the win8.1 or the java in the vassal build, but that is just a guess.
I feel like I am being a PITA. I don’t want to post something that no win8.1 user can not edit if needs be.
You shouldn’t change the module for this. The module is the one thing which can’t be the cause of the problem.
With that absolute and my clean install of 8.1 with all updates applied It tends to point towards the win build or the Java in it?
I can work around it by just using Save as and increase the build number on the mod by .1
could it be that .bak? file?
Please do not do that. It’s unlikely to work.
Please leave everything as-is until I have a chance to give you a diagnostic build.
I do not touch the program J I only work on the Module. I am making do with save as and then after a few name changes I remove the mods created by doing that and revert to a save as to the version number I want to use.
Apologies if I said something out of order. Not intended to make you think I would do anything to Vassal engine, it was just thinking out loud.
We can reproduce the problem now, so you’re clear to do whatever you want on your end. I don’t need you to run any diagnostic build.
Too many times I’ve had people who had a state where they could reproduce a tricky problem make some changes without knowing what they’d done, which then prevented them from reproducing the problem and sending us back to start again.
I am I.T. I don’t Do that sort of thing, I don’t pretend to Know how to work with programing code. I can look around at XML and manipulate it in the Mod, but never in the program.
BTW Thank You. I Think I will be ready to post this TLD as V1.0 soon.
We fixed the problem in PR 11008 earlier today. It wasn’t our bug, but rather a bad interaction between Batik (the SVG renderer) and a poorly designed API in Java.
The fix is in 3.6.3, which was just released.