Thus spake ronljacobsen:
Just noticed your last post. Besides the error log, there are files
called:
key
lock
preferencesalso folders called:
ext
plugins
and 27 temp.zip files.
Delete lock, and then try running VASSAL.
–
J.
Lock deleted. Vassal still does not launch. But I will try reloading it tomorrow and seeing if that makes a difference.
Thus spake ronljacobsen:
Lock deleted. Vassal still does not launch. But I will try reloading
it tomorrow and seeing if that makes a difference.
Check the errorLog again. Is it different now?
Try deleting the key file also.
–
J.
Checked error log, deleted Key, tried launching Vassal (nothing again), then checked error log again. The error log never changed. Still the same set of entries dated Feb 12, 2011. Sigh.
Thus spake ronljacobsen:
Checked error log, deleted Key, tried launching Vassal (nothing again),
then checked error log again. The error log never changed. Still the
same set of entries dated Feb 12, 2011. Sigh.
Rename the directory where you found the errorLog. Then try running
VASSAL. Does that directory get recreated?
–
J.
No, it does not. I renamed the directory containing the errorlog to notVASSAL. Then I tried to launch Vassal. Nothing happened and no new or recreated directory appeared.
I also restarted my computer this morning and the first thing I did was try to launch Vassal. It did not launch, but for what it is worth, the computer thought for about 3 seconds rather than less than a second before not launching.
Thus spake ronljacobsen:
No, it does not. I renamed the directory containing the errorlog to
notVASSAL. Then I tried to launch Vassal. Nothing happened and no new
or recreated directory appeared.
Are you willing to install and run a diagnostic build if I supply one?
–
J.
Possibly, but what does that entail? This is a laptop that I use for work, so I am less willing to take risks with it than my personal desktop at home.
Thus spake ronljacobsen:
Possibly, but what does that entail? This is a laptop that I use for
work, so I am less willing to take risks with it than my personal
desktop at home.
It means installing a special build of VASSAL which will print some
diagnostic output to a terminal window, so we can see how far it’s
getting when you start it.
–
J.
Yeah, that sounds fine. Thanks.
Thus spake ronljacobsen:
Yeah, that sounds fine. Thanks.
Try installing this build:
vassalengine.org/~uckelman/b … indows.exe
Go to the directory where you installed it:
cd C:\Program Files\VASSAL-3.1.19-svn8026
(I’m not sure if this wil be the exact directory name, just have a look
to verify that it is.)
Then, from that directory:
java -cp lib/Vengine.jar VASSAL.launch.ModuleManager
A series of numbers should be printed in your terminal. These are line
numbers in ModuleManager.java, one of our source files. We’ll be able to
use these to see how far execution gets when you try running the
diagnostic build.
–
J.
The output of the program;
88
104
127
144
VASSAL: IO error
java.io.IOException
at VASSAL.launch.ModuleManager.main(ModuleManager.java:155)
Caused by: java.nio.channels.OverlappingFileLockException
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at java.nio.channels.FileChannel.trylock(Unkown Source)
at VASSAL.launch.ModuleManager.main(ModuleManger.java:152)
That’s all of it. Hope I did not make any typos.
Thus spake ronljacobsen:
The output of the program;
88
104
127
144
VASSAL: IO error
java.io.IOException
at VASSAL.launch.ModuleManager.main(ModuleManager.java:155)
Caused by: java.nio.channels.OverlappingFileLockException
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown
Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown
Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at java.nio.channels.FileChannel.trylock(Unkown Source)
at VASSAL.launch.ModuleManager.main(ModuleManger.java:152)
That’s helpful. This shows us exactly where VASSAL is getting hung up.
Now we need to find the path of the file which it’s failling to get a
lock on.
Do the same thing as before, but with this build:
vassalengine.org/~uckelman/b … indows.exe
–
J.
Output is identical to previous except:
After 144, the next line is
\SERVER3\RedirectedFolders\ronjacobsen\VASSAL\lock
And three lines after that “java:155” has changed to “java:156”
I don’t know what SERVER3 and RedirectedFolders are, but if you replace those words wiht C:\Users then it would be the same folder that you had me delete “lock” and “key” from before.
Thus spake ronljacobsen:
Output is identical to previous except:
After 144, the next line is
\SERVER3\RedirectedFolders\ronjacobsen\VASSAL\lock
This points to your problem. Java thinks something still has a lock
on this file.
And three lines after that “java:155” has changed to “java:156”
I don’t know what SERVER3 and RedirectedFolders are, but if you replace
those words wiht C:\Users then it would be the same folder that you had
me delete “lock” and “key” from before.
\SERVER3\RedirectedFolders\ronjacobsen\VASSAL\lock is a path. It’s not
the path I was expecting. Do you have some kind of setup where your home
directory is on a file server when you’re on a particular network, and
local when you’re not?
–
J.
OK, things are starting to become more clear now.
SERVER3 appears to be the name of the server at my office. I use this computer at work, where my main connection is to SERVER3 (which is also listed as our M: drive.) But I also use it at home. Out of convenience, I handle personal items on this laptop at home (such as vassal). That’s not entirely kosher, but its not really a problem either and it is a meaningful convenience for me.
At home, I typically work on my Desktop, or occasionally save to my personal space, which is the U:\ drive. In fact, unless I make a special connection, I am not connected to the M: drive from home. (Note however that Vassal fails to launch similarly, whether I am at the office connected to M: or away from the office.)
I have looked on \server3 (M:) at work and I do not see any directory called RedirectedFolders, so I assume it is something that exists but is hidden with administrator access only. The lock must be in there.
I am not inclined to go to our system administrator and ask to debug the functioning of a personal program like Vassal. So that is likely a dead end.
I guess the remaining quesiton is whether there is a version of Vassal or a way I can install it that will set up using either my U: drive, or better running purely from a flash drive (typically E: on my computer). What do you think? Can I get Vassal to run from E: and not go hunting around on the M: drive for permission to run?
Thus spake ronljacobsen:
OK, things are starting to become more clear now.
SERVER3 appears to be the name of the server at my office. I use this
computer at work, where my main connection is to SERVER3 (which is also
listed as our M: drive.) But I also use it at home. Out of
convenience, I handle personal items on this laptop at home (such as
vassal). That’s not entirely kosher, but its not really a problem
either and it is a meaningful convenience for me.At home, I typically work on my Desktop, or occasionally save to my
personal space, which is the U:\ drive. In fact, unless I make a
special connection, I am not connected to the M: drive from home. (Note
however that Vassal fails to launch similarly, whether I am at the
office connected to M: or away from the office.)I have looked on \server3 (M:) at work and I do not see any directory
called RedirectedFolders, so I assume it is something that exists but is
hidden with administrator access only. The lock must be in there.
Have you tried running the last diagnostic build both on and off the
office network? Which one were you using when you produced the last
output you posted?
–
J.
Until this morning, all of my previous efforts were at home, out of contact with Server3. All the installations of the latest version of Vassal and then your Vassal builds were done Server3 contact not possible. I even uninstalled each version of Vassal before installing the next to try to prevent and carry over from one installation to the next. Later today, I will try an install and execution of your last build while hooked up at work to see if the output is any different.
I am surprised that Vassal is looking for Server3 even though it is not there during either the install or execution. That seems weird unless there is some “piece” of Server3 that is always in my computer.
I will also later try an install of Vassal to a folder on my flash drive and see if anything changes (though I feel like I tried that idea some months ago.)
I’ll get back to you with whatever new info I develop.
I forgot to try to launch the various builds of VASSAL before I left work today. However, when I got home I did try installing VASSAL on a flash drive. I downloaded the install application for the last build of VASSAL to the flash drive and then did a custom installation and chose the flash drive (E:\VASSAL) to be the directory where Vassal was created. I then tried launching vassal directly from Vassal.exe and also from the shortcut on my desktop. Neither worked. I think went to the command prompt and tried to run your java command line from there, however I was unable to change directories to the E: drive. So that stymied me.
Thus spake ronljacobsen:
I forgot to try to launch the various builds of VASSAL before I left
work today. However, when I got home I did try installing VASSAL on a
flash drive. I downloaded the install application for the last build of
VASSAL to the flash drive and then did a custom installation and chose
the flash drive (E:\VASSAL) to be the directory where Vassal was
created. I then tried launching vassal directly from Vassal.exe and
also from the shortcut on my desktop. Neither worked. I think went to
the command prompt and tried to run your java command line from there,
however I was unable to change directories to the E: drive. So that
stymied me.
Installing to a flash drive won’t help, because all that does is change
where VASSAL is installed. The lock file we need to remove is in a
subdirectory of what the system tells Java is your home directory, not
where VASSAL is installed.
Please try running the second diagnostic build while on your work
nework, so we can see if it fails in the same place.
–
J.