(reset!) on duratom to file via nippy throws errors about duratom HOT 9 CLOSED

Hi there, could you elaborate slightly, or even better, provide a code snippet reproducing the problem? Many thanks...

from duratom.

Are you getting this error as soon as you create the duratom with some initial state, by any chance? If yes, I think you may be providing a non existent file path, and the duratom is trying to persist that initial state upon creation. If no (the error is NOT thrown on creation), then I'll have to see the stacktrace, and ideally, a small repro code-snippet.

from duratom.

the problem looks like it's related to creating the .tmp file
i did some tracing of nippy and duratom, but wasn't able to come to a reasonable conclusion of what was causing the problem.

the paths i use are ok, when i don't use nippy things work fine.
also the duratom file is created (empty).

i'll whip up a code snippet (it'll just be config and reset!)

from duratom.

hmm
i think this may be a related to using ~ in file paths. because now things seem to be working fine. though differently from yesterday.

when i use a ~ i get

   Error compiling NO_SOURCE_FILE at (8:8)
   #:clojure.error{:phase :execution,
                   :line 8,
                   :column 8,
                   :source "NO_SOURCE_FILE"}
             Compiler.java: 3707  clojure.lang.Compiler$InvokeExpr/eval
             Compiler.java:  457  clojure.lang.Compiler$DefExpr/eval
             Compiler.java: 7182  clojure.lang.Compiler/eval
             Compiler.java: 7132  clojure.lang.Compiler/eval
                  core.clj: 3214  clojure.core/eval
                  core.clj: 3210  clojure.core/eval
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   79  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   55  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  142  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  171  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  170  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  835  java.lang.Thread/run

1. Caused by java.io.IOException
   No such file or directory

again, not the problem i was seeing yesterday, which was related to moving a tmp file to a different file name.

I'm not on the same code base right now, so i'll try again on the code that was giving me the weird tmp err a little later.

from duratom.

I tried to reproduce your suspicion, with the ~, but I couldn't:

(spit "/home/dimitris/Desktop/a~b.txt"     "whatever")   
(spit "/home/dimitris/Desktop/a~b.txt.tmp" "whatever2")    
(ut/move-file! "/home/dimitris/Desktop/a~b.txt.tmp" 
               "/home/dimitris/Desktop/a~b.txt")
=> #object[sun.nio.fs.UnixPath 0x350aa96f "/home/dimitris/Desktop/a~b.txt"]

And cat ~/Desktop/a~b.txt on my terminal returns whatever2 (as expected).
Moreover, I find it rather surprising that w/o nippy things work, as I don't see how nippy can possibly be involved in this. The atomic move of the temp file happens entirely in duratom.utils/move-file! - nippy can only be responsible for filling that temp file. Very odd stuff indeed...I really can't wait for a small repro case now! Thanks again ...

from duratom.

yeah, i was looking in ut/move-file! as well. i'm pretty sure that the tmp file wasn't being made at all, and when the move-file was called it threw because of that.

however, on my new test, just making a duratom with ref to a file-path of "~/whatever" fails. (as in talked about in my last reply)

it's possible that my cider or deps were screwed up on my other codebase. recently it's been an issue, so maybe i just didn't quit and jack-in when trying to solve this problem.

from duratom.

Oh wait a second...

~/whatever only makes sense in the context of bash - NOT Java! You can't expect Java to expand ~ to the super Unix-specific /home root path, right? Observe this:

(slurp "~/Desktop/words.txt") ;; this file exists
=> Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2).
~/Desktop/words.txt (No such file or directory)

Can you try with a full path + nippy when you get the chance? Thanks in advance...

from duratom.

fwiw, we've encountered these tilde issues before. This may be relevant:

user> (System/getProperty "user.home")
"/home/harold"

Long live duratom.

from duratom.

haha, oh man i am so used to shells.

from duratom.