Creating a separate issue for this, since it is actually quite a major problem:

Spoofax replicates the stratego.jar and the stratego-javastrat.jar that are inside the binary of a language (e.g. pgql.spoofax-language), onto the file system, into a directory /tmp/vfs-cache/.
The problem with this is that if a user A first creates the vfs-cache directory, then a user B may not have write access to it and Spoofax will thus crash for him.

Ultimately, Spoofax should use some virtual file system to replicate files to. Alternatively, the replicator should not use a static temporary directory but a random one:

String baseTmpDir = System.getProperty("");
File tempDir = new File(baseTmpDir, "vfs_cache" + new Random().nextLong()).getAbsoluteFile();
DefaultFileReplicator replicator = new DefaultFileReplicator(tempDir);

Maybe do that in org.metaborg.core/src/main/java/org/metaborg/core/resource/

It’s kind of a VFS bug IMO, but I think you’ll have to work around it.

In the meantime, this is a temporary workaround that Spoofax users can use:

((DefaultFileSystemManager) VFS.getManager()).setReplicator(replicator); where replicator is created like above.

Submitted by Oskar van Rest on 19 May 2016 at 03:19

On 19 May 2016 at 13:11 Gabriël Konat commented:

You can override the DefaultFileSystemManagerProvider by creating a module that inherits from SpoofaxModule, and overriding the bindResource method there to inject a different FileSystemManagerProvider:

@Override protected void bindResource() {


However, the change you propose makes sense. Can you make that change (licensed under Apache 2.0) and open a PR, or is that against Oracle policy? :)

On 19 May 2016 at 13:15 Gabriël Konat commented:

Also, about your other comment that Spoofax does not clean up its temporary resources, it actually does!

If you set up the Spoofax facade via the try-with-resources statement like shown here, Spoofax will clean up temporary resources when exiting the try statement.

On 19 May 2016 at 21:47 Oskar van Rest commented:

Ok thanks! Didn’t realize it was already cleaning up.

Very happy to make my first Apache 2.0 PRs :P

On 20 May 2016 at 10:22 Gabriël Konat commented:

Merged, thanks!

On 20 May 2016 at 10:22 Gabriël Konat closed this issue.

On 6 April 2017 at 00:23 Oskar van Rest reopened this issue.

On 6 April 2017 at 00:23 Oskar van Rest commented:

somehow my pull request did not have any affect. This is still an issue in 2.1.0. Not sure where to set the replicator if not in that file.

On 6 April 2017 at 11:01 Gabriël Konat commented:

It is still creating /tmp/vfs-cache/ instead of /tmp/vfs-cache<longnumber>/?

On 7 April 2017 at 05:23 Oskar van Rest commented:

Yes still the /tmp/vfs-cache. Martin ran into it with GM (Spoofax 2.1.0). With PGQL I was still using the workaround.

On 23 November 2017 at 23:49 Oskar van Rest commented:

Issue is solved now. At least in Spoofax 2.3.0 it is no longer creating /tmp/vfs-cache/. I think previously we tested it wrongly and forgot to use spoofax.resourceService.resolve(..) instead of VFS.getManager().resolveFile(..) in a few places. Closing the issue.

On 23 November 2017 at 23:49 Oskar van Rest closed this issue.

Log in to post comments