vasl on Mac keeps "disappearing"

[jrv]

My opponent for tomorrow has a Mac with vasl installed. My understanding of his problem is that every so often when he goes to run VASSAL, the list of module libraries in the VASSAL window resets. He browses to the vasl module, and the module is added to the list. It stays for a couple days, then resets. Any ideas? I've seen nothing like it on windows or linux, but I install the program in places where I know what will happen to it. As one possible problem, he may have it in an "odd' place on his Mac.

JR

 

[zgrose]

Is the V_Global file gone/empty/accessible?

 

[jrv]

Is the V_Global file gone/empty/accessible?

I have no idea. I have not seen the machine yet. Where is it (supposed to be) stored on a Mac? I don't see any setting for choosing a directory to place it in. On my (linux) machine it shows up in ~/.VASSAL/prefs/ and never causes me trouble. Is it the same on a Mac?

One thing that occurred to me is that the V_Global file is either in a place that is not really accessible or is erased regularly. The player in question could be keeping his machine "up" (hibernating but not really shutting down) for several days, then when he really shuts down, vasl loses the in-memory version and it can't save the settings to disk. But I don't know how likely that is on a Mac. I try to stay away from Macs.

JR

 

[hongkongwargamer]

Yup .. it's been happening since Catalina .. I just "Open" the vmod again and keep playing. But it is an issue.

 

[zgrose]

~/Library/Application Support/VASSAL/prefs

 

[hongkongwargamer]

~/Library/Application Support/VASSAL/prefs

Hmmm .. I don't have a VASSAL/prefs under Application Support .. it's the folder with my user name. I just pasted it back in there ..

 

[zgrose]

That was Mojave, I'll confirm on Catalina...

 

[zgrose]

Seems like it is there (at least for a little while)....

Did you leave out the ~ at the front to get to your user-specific library?

 

[hongkongwargamer]

Seems like it is there (at least for a little while)....

Did you leave out the ~ at the front to get to your user-specific library?

View attachment 10651

I used the FINDER to get there

 

[zgrose]

I used the FINDER to get there

Ah. That may be why. Shift-Command-G and try this:


and see if you can find VASSAL now.

 

[hongkongwargamer]

Ah. That may be why. Shift-Command-G and try this:
View attachment 10652

and see if you can find VASSAL now.

View attachment 10653

Thanks mate .. got there .. but no VASSAL

 

[jrv]

On inspection I didn't see anything odd about the setup. Permissions looked normal, and it looked as though the VASSAL was finding the V_Global file. The directory with modules was present in that file (modulesDir, although that may not do what I think it does), but no recent modules. The one item I noted was that the folder in which the modules were being stored had spaces in the name, both at the start of the name and in the middle. I removed the space at the start of the folder name and replaced the others with underscores. According to the owner it remembers for a few days then loses the settings. I had him reboot the system and after the module was still listed, but I don't know if that was sufficient to force it to reset all the software. Only time will tell if that alleviates the problem.

JR

 

[zgrose]

Is this a 10.15 Catalina user?

 

[jrv]

Is this a 10.15 Catalina user?

It was Catalina. I didn't look at the exact version number. I don't think the owner does anything unusual with updates like blocking them, so it is most likely the latest that Apple would send automatically.

JR

 

[zgrose]

Does seem like a recurring issue with Catalina.

 

[jrv]

I tried duplicating the issue on linux, but spaces in a directory name did not faze vassal there. I suggested the possibility because unix-like systems can have problems with spaces in names. However such difficulties tend to occur in shell scripts, which I don't think should be in play here. There is a script, but it does not use the module directory in any way I see.

Assuming that the problem is not with spaces, then my next guess is that the OS or some other program is saving old versions of the file and restoring them. I find it hard to believe it is a deliberate action by the OS, from my meager understanding of the mac file system. I don't believe the ~/Library directory is intended to be read-only. Is it possible that something like apple cloud (of which I know very little) is doing this? It looks as though V_Global treats lines that begin with a hash ('#', octalthorpe) as comments. Perhaps add a comment (e.g. "# hello world") to V_Global, then observing if it goes away would be diagnostic. The machine at which I was looking is not one to which I have regular access, so I can't give much more direction.

JR

 

[jrv]

The Mac owner reports that VASSAL has "forgotten" its recent modules again. He says he doesn't use iCloud. If it were my machine I would put in the hash comment and see if that disappeared. I would also try to figure out how apple runs timer jobs, then see if I could figure out which timer job was trashing the file. I might even build my own timer job to watch the hash comment so I could get a good time on when it disappeared (just run grep on the file say every five minutes and add a time stamp). Of course that's only based on my hypothesis that something outside is erasing the recent modules. It could still be vassal.

No wait. If it were my machine I would format the hard drive and put on ubuntu. But the above might get some clues about what is happening on the Mac.

JR

 

[zgrose]

its a Unix based OS. I bet you can do all these things.

its likely just some odd interaction with the updated security features, though.

 

[jrv]

its a Unix based OS. I bet you can do all these things.

its likely just some odd interaction with the updated security features, though.

You are probably correct that I could do those things if I had a Mac or ready access to one, but I do not. From what I recall the V_Global file was written with the recent modules data, i.e. I looked at the contents of the V_Global file. So if it's security, it's not security in the sense of blocking write to a file. It seems like some other program is restoring the file to a previous state. That's a strange sort of security, because assuming the file is in fact compromised, it remains compromised "for a while." But again I don't have a Mac to experiment with, nor do I know how the OS differs from linux, nor least of all do I know what the updated security features in Catalina are.

JR

 

[zgrose]

The error is:

2019-10-28 14:31:24,430 [0-AWT-EventQueue-0] ERROR VASSAL.build.module.metadata.MetaDataFactory - 
java.io.FileNotFoundException: /Users/zgrose/Downloads/vasl-6.4.4.vmod (Operation not permitted)
    at java.base/java.io.RandomAccessFile.open0(Native Method)
    at java.base/java.io.RandomAccessFile.open(Unknown Source)
    at java.base/java.io.RandomAccessFile.<init>(Unknown Source)
    at java.base/java.io.RandomAccessFile.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile$Source.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile$Source.get(Unknown Source)
    at java.base/java.util.zip.ZipFile$CleanableResource.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
    at VASSAL.build.module.metadata.MetaDataFactory.buildMetaData(MetaDataFactory.java:62)
    at VASSAL.launch.ModuleManagerWindow$ModuleInfo.loadMetaData(ModuleManagerWindow.java:1231)
    at VASSAL.launch.ModuleManagerWindow$ModuleInfo.<init>(ModuleManagerWindow.java:1259)
    at VASSAL.launch.ModuleManagerWindow.buildTree(ModuleManagerWindow.java:481)
    at VASSAL.launch.ModuleManagerWindow.<init>(ModuleManagerWindow.java:376)
    at VASSAL.launch.ModuleManagerWindow.<clinit>(ModuleManagerWindow.java:178)
    at VASSAL.launch.ModuleManager.launch(ModuleManager.java:455)
    at VASSAL.launch.ModuleManager$2.run(ModuleManager.java:342)
    at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
    at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
    at java.base/java.security.AccessController.doPrivileged(Unknown Source)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
2019-10-28 14:31:24,435 [0-AWT-EventQueue-0] INFO  VASSAL.launch.ModuleManagerWindow - Module /Users/zgrose/Downloads/vasl-6.4.4.vmod not found - Removed.

I'll dig a bit more to see if I can find what's triggering the new security options.