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")
Zeta
  • 1,093
  • 9
  • 18
  • Do you know what package or process created these cache files via url? – roomworoof Jun 01 '23 at 08:42
  • @roomworoof Yeah, it's https://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 Jun 01 '23 at 08: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 Jun 01 '23 at 09: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 Jun 01 '23 at 09: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 Jun 01 '23 at 09:21
  • Does M-x toggle-debug-on-error get you a backtrace? If so, add that to your question. – phils Jun 01 '23 at 09:24
  • @phils The backtrace is inconclusive, since the stems from the asynchronous callback and doesn't show the actual caller :/ – Zeta Jun 02 '23 at 07:32
  • It does indicate that you have some advice in place for url-cache-extract though. What is that? From the naming it's old-school defadvice so you may need to M-x rgrep your config for url-cache-extract to find out where that's being defined. – phils Jun 02 '23 at 07:53
  • Actually, that looks weird / maybe an Emacs bug. It seems strange that when url-http-generic-filter runs the cached file wouldn't be present, unless maybe there was a file permissions problem preventing it from being cached in the first place. I do note that url-http-parse-headers isn't testing url-is-cached though, but I also don't know whether it has options for proceeding if the cache file isn't there. I've not looked at this in-depth though, so I'm unsure of what should be happening here. – phils Jun 02 '23 at 08:07
  • Notice the http status code string "HTTP/1.1 304 NOT MODIFIED". From my point of view, what this means, already at the beginning of this backtrace, it is determined that the cache exists and it is already impossible to fall back. So the causal point is the process that passed 2nd parameter data to url-http-generic-filter with the http status code outside of this backtrace. – roomworoof Jun 02 '23 at 10:16
  • @phils about the "defadvice": nope, that was a red herring by a restclient autoload. I've adjusted the backtrace after removing the package. – Zeta Jun 02 '23 at 10:39
  • The crash might have destroyed some other things. For some reason, all Info pages have encoding issues. Or the crash (and the weird behavior now) was only a symptom of a failing drive, no idea :/ – Zeta Jun 02 '23 at 11:03

1 Answers1

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)
roomworoof
  • 459
  • 2
  • 10
  • Tried this one, didn't work unfortunately, the issue still persists :(. Thanks though – Zeta Jun 02 '23 at 11:06