Recentf Save Gets Blocked by Interlocking

[rye]

In my daily life, I walk around a lot. Emacs opens recentf a bunch, but it seems like it never really writes it to disk. (Evidenced by the fact that #recentf# is always left over in ~/.emacs.d except when the 5-minute #'recentf-save-list timer gets run.)

This is bad, because Emacs has support for preventing simultaneous edits, and when I change networks my hostname changes. Emacs then blocks my workflow and asks me if I want to steal the lock from myself. This is highly frustrating.

So, should we: (a) disable interlocking support entirely, via setting create-lockfiles to nil globally, or (b) do something more intelligent? I'm going to leave this to @cg505 because I have never used recentf before.

[cg505]

iirc you literally can't disable interlocking without editing the C source of emacs. this is a very strange issue that I've never experienced. emacs should not be hanging around with recentf open and modified. this is something we should dig into if it's happening with any regularity.

[rye]

If you set create-lockfiles to nil as I suggested, this problem no longer is apparent.

[rye]

But Emacs should not be hanging around with recentf open and modified, and yet it is.

[cg505]

Oh nice. That's literally a new feature since I last looked into it.

[cg505]

I can't reproduce the issue. Maybe check the permissions on the recentf file?

[cg505]

The code in recentf.el literally just makes a temp buffer, dumps the stuff it needs, and writes the file. That's it. It shouldn't be hanging around open in a buffer or anything. I don't even think emacs needs to take out a lock on it.

[cg505]

Additionally, when it's loaded, it's literally just a call to #'load so that should also be a nonissue. I'm really not sure what is causing this. Can you give any more detailed steps to reproduce?

[rye]

I can't reproduce the issue.

Have you tried changing networks? That's what causes the problem for me—I've isolated the rest of the variables behind this.

Can you give any more detailed steps to reproduce?

Try changing networks and editing files for more than 5 minutes. Since #'recentf-save-list is called on a 5-minute timer, that would lead me to believe that you have to wait for that. Are you on macOS? I doubt that'd cause any problems.

[rye]

Also, I might just go ahead and PR turning off lockfiles.

[cg505]

I do most of those things relatively frequently and I'm pretty sure I would have run into the issue. At this point I can't even get a .#recentf- file created by doing anything. I don't have a machine I can test on macOS (only my work desktop).

I would just recommend that next time you see this issue, check to see when the lockfile was created and if recentf is open in a buffer on your machine. That may help us narrow it down. If you want lockfiles off I would do it in your personal config for now. They do have a purupose.

[rye]

To answer your question, yes, the lockfile is created 5 minutes after the previous recentf save, and yes, recentf is open in a buffer when this condition takes place.

[cg505]

I will try and look at this issue on a MacOS machine on Monday but if I rail to reproduce it I have no plan for proceeding with it.

[cg505]

I can't reproduce in any capacity. I'm closing unless we get more information that would allow us to proceed.

[rye]

When you change networks, does your hostname change?

[rye]

I reopened this for tracking purposes. We might want to just disable interlocking via setting create-lockfiles to nil, which solves this problem.

[rye]

I will try and reproduce it again this morning when I head over to work.

[rye]

Hm. I was unable to reproduce this again reliably. If we're shying away from setting create-lockfiles to nil, which I still maintain is a decent idea, then this issue can be closed.

[cg505]

I didn't check to see if my hostmane changed. However, I couldn't get recentf to create a lockfile without manually opening the recentf file and modifying it by hand. Even then, #'recentf-save-list correctly handled the situation (probably because my hostname didn't change). I would recommend that if you are having issues with lockfiles to disable them in your personal config. Unless this issue is experienced by someone else, I don't think it's sufficient reason to turn set create-lockfiles to nil.

[rye]

Okay. Then I think it's safe to close this issue now.

[cg505]

Randomly was able to reproduce this issue today. Investigating.

[cg505]

syl20bnr/spacemacs#5186 looks related. No resolution there, however.

[cg505]

What seems to happen is that during save, recentf throws the error Non-character input-event and then leaves the lock open on the file. That error seems pretty elusive.

Nope, pretty sure this is unrelated on more investigation. Somehow the save leaves the lock open but doesn't error?

[rye]

No resolution there, however.

Check out this comment; it's not an elegant solution but one could patch over the ask-user-about-lock function and just return t if the file is a recentf file. This seems to be due to an internal problem; as we had previously concluded, recentf-mode handles this problem fairly well.

[cg505]

I would be fine with advising ask-user-about-lock as a temporary fix. However, I am of the opinion that we should leave this issue open and a comment in the code describing the issue until we uncover the actual issue and can fix that.

[rye]

Agreed, this all sounds good.

[cg505]

The issue occurs when multiple instances of emacs are running. To solve this, we could adjust the time at which recentf saves to be dependent on the PID or something, instead of having all processes try to save exactly every 5 minutes and then conflicting with each other.

[cg505]

So, this still happens and it seems increasingly clear that multiple emacs processes will of course all try and write the recentf file at the same time, and that obviously doesn't work. Of course, if you have multiple emacs processes open, there isn't really any way to sync recentf across these different files, so they are going to ultimately end up overwriting each other's changes. I propose simply modifying the run-at-time call so that it doesn't sync each run to the nearest five minutes, and instead just runs every five minutes, starting from whenever this emacs process was launched.

[cg505]

@rye if this seems fine, I can take it.

[rye]

Thanks for taking the initiative and looking further into this. I like your proposed solution a lot. Go on ahead if you want.