If a directory is scanned twice with the same directory, but with different (non-canonical) root directories supplied to c.t.n.dir/scan-dirs, files in the directory will be considered "deleted" and subsequently "unloaded" by c.t.n.reload.
This can happen after using c.t.n.repl/set-refresh-dirs with non-canonical (i.e. local) directory paths.
The foo namespace should still exist after the second call to refresh, but it has been removed. Calling refresh a third time will not recover the file, because its timestamp has not changed since the previous call.
Note that this does not happen if the foo namespace has no dependencies, because it will not be present in the tracker's dependency map and therefore is never considered as a candidate for unloading.
Major
If a directory is scanned twice with the same directory, but with different (non-canonical) root directories supplied to
c.t.n.dir/scan-dirs, files in the directory will be considered "deleted" and subsequently "unloaded" byc.t.n.reload.This can happen after using
c.t.n.repl/set-refresh-dirswith non-canonical (i.e. local) directory paths.Steps to reproduce
In a shell:
mkdir demo cd demo mkdir src lib echo "(ns foo (:require clojure.set))" > src/foo.cljCopy the following JAR files into the
libdirectory:clojure-1.8.0.jar java.classpath-0.2.3.jar tools.namespace-0.3.0-alpha3.jar tools.reader-1.0.0-beta4.jarBack in the shell, in the project directory:
java -cp src:lib/* clojure.main Clojure 1.8.0 user=> (require 'clojure.tools.namespace.repl) nil user=> (clojure.tools.namespace.repl/refresh) :reloading (foo) :ok user=> (clojure.tools.namespace.repl/set-refresh-dirs "src") ("src") user=> (clojure.tools.namespace.repl/refresh) :reloading () :ok user=> (find-ns 'foo) nilThe
foonamespace should still exist after the second call torefresh, but it has been removed. Callingrefresha third time will not recover the file, because its timestamp has not changed since the previous call.Note that this does not happen if the
foonamespace has no dependencies, because it will not be present in the tracker's dependency map and therefore is never considered as a candidate for unloading.