jeremyevans/rack-unreloader

crashes with emacs interlock files

fdr opened this issue · 3 comments

fdr commented

Emacs uses a nominally hidden file (when a buffer is modified but not explicitly saved) when a buffer gains unsaved modifications, looking like .#foo.rb

It's a symlink, but not to a non-existent path. Emacs reads the link text and interprets it specially.

Unreloader tries to load these and yield to a block, but crashes internally:

/home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:29:in `realpath': No such file or directory @ rb_check_realpath_internal - /home/fdr/code/clover/prog/.#heartbeat.rb (Errno::ENOENT)
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:29:in `block in autoload_dependencies'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:23:in `each'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:23:in `autoload_dependencies'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:65:in `check_autoload_dir'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:26:in `block in autoload_dependencies'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:23:in `each'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader/autoload_reloader.rb:23:in `autoload_dependencies'
	from /home/fdr/.asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rack-unreloader-2.1.0/lib/rack/unreloader.rb:173:in `autoload'
	from /home/fdr/code/clover/loader.rb:56:in `block in <top (required)>'
	from /home/fdr/code/clover/loader.rb:88:in `block in <top (required)>'
	from /home/fdr/code/clover/loader.rb:88:in `each'
	from /home/fdr/code/clover/loader.rb:88:in `<top (required)>'
	from ./bin/pry:6:in `require_relative'
	from ./bin/pry:6:in `<main>'

Here's the stat information. 10382 is my emacs PID.

fdr@shrike ~/c/clover ((f733788d)) [1]> stat /home/fdr/code/clover/prog/.#heartbeat.rb
  File: /home/fdr/code/clover/prog/.#heartbeat.rb -> fdr@shrike.10382:1695769130
  Size: 27        	Blocks: 0          IO Block: 4096   symbolic link
Device: 253,3	Inode: 2757413     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/     fdr)   Gid: ( 1000/     fdr)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2023-09-29 14:38:47.968099443 -0700
Modify: 2023-09-29 14:38:42.382042002 -0700
Change: 2023-09-29 14:38:42.382042002 -0700

There's probably a number of viable solutions for this, but it's rather unfortunate that a stray keystroke results in autoloader crashing my startup, and there's not much I can do about (e.g. ignore such symlinks) it since control is not yet yielded to my program.

The obvious solution is to change your emacs configuration to not create such symlinks ((setq create-lockfiles nil)). :) However, I'm open to a option to ignore files based on a regexp. Is that something you feel comfortable implementing?

fdr commented

I might do that, I don't find the feature that useful, but then again, I can't think of another library I've used where things go quite so badly (generally, things going badly are made my problem as file paths are yielded to the block without trying to work with them first)

OK. I'm going to close this now. It's not a bug in rack-unreloader, because if you tell rack-unreloader to monitor a directory, it will look for any new/modified .rb files in that directory or subdirectories, and that is what emacs is creating. I'm still open to a pull request so you can filter the files by regexp.