This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
but i think it's pretty likely that there are other places in libraries where this happens
see https://github.com/boot-clj/boot/issues/117 for example
oh cool, fix coming in 1.8 http://dev.clojure.org/jira/browse/CLJ-1659
@symbit: the fileset implementation is here https://github.com/boot-clj/boot/blob/master/boot/pod/src/boot/tmpdir.clj
Yes, Issue 117 is the same root cause that I'm seeing and it looks like it's a FileDescriptor leak in Clojure 1.7, which will be fixed for Clojure 1.8. I upgraded to 1.8-alpha5 at least for dev, but ClojureScript has the same issue as Alex pointed out.
clojure.lang.Compiler$CompilerException: java.lang.VerifyError: (class: cljs/util$last_modified, method: invokeStatic signature: (Ljava/lang/Object;)Ljava/lang/Object;) Can only throw Throwable objects, compiling:(util.cljc:142:1) java.lang.VerifyError: (class: cljs/util$last_modified, method: invokeStatic signature: (Ljava/lang/Object;)Ljava/lang/Object;) Can only throw Throwable objects
ah, that's another clj bug
It looks like the same smoking gun as the Clojure bug that was fixed. Alex Miller noted that it exists in CS as well.
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/util.cljc#L142
util.cljs is patched https://github.com/clojure/clojurescript/commit/7f29513de3ace7a14df220f4d0be1a8faeb92723
I updated the boot.build to the latest of clojure and clojure script, but am getting the exception above when running boot dev on the address-book example. Also tried updating boot.properties to use 1.8.0-alpha5 as the boot version, still no dice. I noticed that the boot.properties in the ~/.boot/cache/ says 1.7.0 despite removing the cache dir. Any Ideas?
@symbit: i think 1.8-alpha5 has the file system fix, but has the verifyerror bug
@symbit: you may consider building and deploying your own 1.7 with the last modifiied patch applied
@symbit: sorry, that new 1.8 bug you're seeing is http://dev.clojure.org/jira/browse/CLJ-1809
@alandipert: Thank Alan. I'll go the custom 1.7 route. Interesting to see 1809 is yet another unrelated bug. Yikes.
@symbit: eg. BOOT_CLOJURE_NAME=me.micha/clojure BOOT_CLOJURE_VERSION=1.8.0-micha1 boot ...
symbit: are you pretty good with windows scripting? we'd like to have a script that calls the boot jar instead of the launch4j thing, i think
I'm using my patched 1.7.0 clojure version, but on change of the src file I get the same: java.io.IOException: Couldn't delete C:\Users\me\.boot\cache\tmp\somedir\dev\clj\address-book\4aw\gg42n1\index.html.out for every file in the cache being moved/deleted.
yeah i think the odds of fixing every open stream in every dependency you might have is not really feasible
The last line of the stack trace is different: java.nio.file.FileAlreadyExistsException: C:\Users\me\.boot\cache\tmp\somedir\dev\clj\address-book\4aw\gg42n1\index.html -> C:\Users\me\.boot\cache\tmp\somedir\dev\clj\address-book\4aw\-7kd6cy\a3e4acfecc74eee2a20111610f7c9624
Is this an example of a file in the fileset? java.nio.file.FileAlreadyExistsException: C:\Users\me\.boot\cache\tmp\somedir\dev\clj\address-book\4aw\gg42n1\index.html
calling gc() multiple times seems to help, i've experimented with that for other purposes before
boot needs 2-3 different pods with different dependencies when it starts up and prepares to run your build.boot
the boot.exe thing is just a shim that gets maven working and craetes the pods boot needs to bootstrap itself
Will try this.. http://stackoverflow.com/questions/1879885/clojure-how-to-to-recur-upon-exception
Ha! I'm guessing that something is holding on to the file handles. Perhaps the Browser? Numerous files in the cache are trying to be deleted without success.
I'm using ProcessExplorer to see which process is holding on to the cache dir. It's the Java process.
In windows if an app has a file open, no one can remove the directory the file is in or any parent directory the file is in, unlike in Unix.
ok, just an example. Same goes for files. If you are editing a file in windows you can't delete the file from another process.
there is a tool that was used to see which java code was opening input streams and not closing them
So boot is creating files in dir X then moving them dir Y. When I edit the source file what is trying to do? From the output on windows at least it looks like it's trying to delete all the files in the cache.
I could try to mimic what boot is doing to see if I can recreate the issue or prove that the file can be closed, which would mean boot has to close in another way or something.
a background thread monitors your source paths and copies files into the tempdir whenever anything is added or changed
when it does this it takes all the files in that tempdir and copies them to the blob storage dir if necessary
when you call commit!
on a fileset object, it creates hard links from other tempdirs that are in the classpath to blob files
well actually it deletes all the existing hard links and then rebuilds them according to the fileset object map
and when the fileset is created to build the project it gets copied into the blob storage
I set hard-link to false. The first change/save to index.cljs.hl, compiled fine, but the browser didn't refresh.
However subsequent changes to the source file throws: java.io.FileNotFoundException: C:\Users\me\.boot\cache\tmp\somedir\dev\clj\address-book\5jc\-yrrdlm\index.html.js (The requested operation cannot be performed on a file with a user-mapped section open)