deleting memory-mapped temporary files on Windows

Development
1

Deleting memory-mapped temporary files on Windows is turning out to be
a real bugger. Here’s a list of things which haven’t worked for me:

  1. File.deleteOnExit() appears not to work on Windows all that well.

  2. File.delete(). This fails when I do it directly.

  3. Nulling all references to the MappedDataBufferInt, and running
    System.gc() a bunch of times so that the files get unmapped, and then
    calling File.delete().

  4. All of the suggested work-arounds suggested by commenters on this bug:

bugs.sun.com/bugdatabase/view_bu … id=4724038

  1. Runtime.addShutdownHook(), because it seems not to be called sometimes
    on Windows, or at least seems not to be allowed to run to conclusion.

  2. Renaming the files, and then deleting them. Fails on the renaming.

I really don’t like the idea of leaving last session’s temp files to be
cleaned up by the next session—we should have VASSAL check for old temp
files to remove on startup, but I don’t want that to be the usual way
that temp files are removed.

Is it possible to spawn another process which will delete the temp files
after the main process has ended?

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

2

Thus spake Joel Uckelman:

Answer: Yes.

It works on Windows to call

Runtime.getRuntime().exec("cmd /c del " + tmpFiles)

from a shutdown hook, where tmpFiles is a space-separated list of temp
files to delete. Apparently the process spawned by exec runs after
the memory-mapped temp files have been unmapped, and so is able to remove
them.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

3

I was wrong. It turns out that this isn’t reliable.

A more reliable solution is to keep initiating garbage collection until the mapped data buffers are collected—and then delete the files. This does appear to work reliably, and is in build svn2750.