0

My Emacs crashed, and now it seems like my url cache is poisoned:

error in process filter: Opening input file: No such file or directory, c:/Users/zeta/.emacs.d/url/cache/zeta/http/localhost/ffa50f273d94812bd23dff56a1ca0757 [2 times]
error in process filter: Opening input file: No such file or directory, c:/Users/zeta/.emacs.d/url/cache/zeta/http/localhost/dc0cdf4984e3f18ede59d4de6a263e14 [2 times]
error in process filter: Opening input file: No such file or directory, c:/Users/zeta/.emacs.d/url/cache/zeta/http/localhost/ffa50f273d94812bd23dff56a1ca0757 [2 times]

How can I force url to forget its cache in order to get rid of those messages?

For completeness, here is the accompanying backtrace (with multiline enables and all ellipsis expanded):

Debugger entered--Lisp error: (file-missing "Opening input file" "No such file or directory" "c:/Users/zeta/.emacs.d/url/cache/zeta/http/localhost/ffa50f273d94812bd23dff56a1ca0757")
  insert-file-contents-literally("c:/Users/zeta/.emacs.d/url/cache/zeta/http/localhost/ffa50f273d94812bd23dff56a1ca0757")
  url-cache-extract("c:/Users/zeta/.emacs.d/url/cache/zeta/http/localhost/ffa50f273d94812bd23dff56a1ca0757")
  url-http-parse-headers()
  url-http-wait-for-headers-change-function(1 124 123)
  url-http-generic-filter(#<process localhost> "HTTP/1.1 304 NOT MODIFIED\15\nServer: Werkzeug/2.1.2 Python/3.9.13\15\nDate: Fri, 02 Jun 2023 10:38:32 GMT\15\nConnection: close\15\n\15\n")
Improve this question
12
  • Do you know what package or process created these cache files via url?
    – roomworoof
    Commented Jun 1, 2023 at 8:42
  • @roomworoof Yeah, it's github.com/pauldub/activity-watch-mode. It sends a request at the local activity-watch instance whenever I change buffers, which makes Emacs unusable due to the amount of errors when global-activity-watch-mode is active. But I'm more interested in a generic solution if possible.
    – Zeta
    Commented Jun 1, 2023 at 8:50
  • I've deleted the ~/.emacs.d/url directory before asking this question but after experiencing the issue :). I have no idea how url still thinks there is some cache.
    – Zeta
    Commented Jun 1, 2023 at 9:17
  • And given that this is Windows: yes, request-backend is set to 'url-retrieve to ensure that Windows' own curl does not break stuff. Everything worked fine until the crash today :/
    – Zeta
    Commented Jun 1, 2023 at 9:20
  • My reading of url-cache.el indicates that the test for whether a URL is in the cache or not is simply whether the hashed filename exists, so it makes little sense that an attempt was then made to go ahead and read a file which would have failed that initial test by virtue of not existing (race conditions aside). Maybe change url-cache-directory and check whether or not the errors still refer to the old directory. If so, then the url cache probably isn't the problem. (Something elsewhere may be hanging onto those filenames.)
    – phils
    Commented Jun 1, 2023 at 9:21

1 Answer 1

Reset to default
0

How about setting the cache expiration time to 0 to see if url is the direct cause? And you can eval (url-cache-prune-cache) to force cleanup for the first time.

(setq url-cache-expire-time 0)
(url-cache-prune-cache)
Improve this answer
1
  • Tried this one, didn't work unfortunately, the issue still persists :(. Thanks though
    – Zeta
    Commented Jun 2, 2023 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.