.swp files can't be deleted because Vim is always PID 3

[wjt]

If you open foo.txt in Vim, it writes .foo.txt.swp alongside it. This file is used for crash recovery (among other things) and is removed when you close the file in Vim, or exit Vim cleanly. The file embeds the PID of the Vim process itself.

When you open a file for which a .swp file already exists, Vim reads the PID from the file, and checks whether a Vim with that PID is running. If not, it offers you the option to delete the temporary file; if so, it says "(still running)" and won't let you delete it.

However, the Flatpak is always launched in a new PID namespace, so (in practice) it's always PID 3. After a crash, the new Vim process looks for PID 3 and finds itself.

[debarshiray]

I wonder if it would be possible to attach a second identifier to the PID. eg., a timestamp. However, I have no idea what the format of the .swp file is, and whether it can accommodate such a thing.

[fmuellner]

I wonder if it would be possible to attach a second identifier to the PID. eg., a timestamp.

If flatpak-specific handling is acceptable, maybe the instance-id field from /.flatpak-info?

[wjt]

An example of the error:

E325: ATTENTION
Found a swap file by the name "src/.memline.c.swp"
          owned by: wjt   dated: Tue Jul 02 21:23:47 2019
         file name: ~wjt/src/vim/vim/src/memline.c
          modified: no
         user name: wjt   host name: camille
        process ID: 3 (STILL RUNNING)
While opening file "src/memline.c"
             dated: Tue Jul 02 20:51:19 2019

(1) Another program may be editing the same file.  If this is the case,
    be careful not to end up with two different instances of the same
    file when making changes.  Quit, or continue with caution.
(2) An edit session for this file crashed.
    If this is the case, use ":recover" or "vim -r src/memline.c"
    to recover the changes (see ":help recovery").
    If you did this already, delete the swap file "src/.memline.c.swp"
    to avoid this message.

Swap file "src/.memline.c.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort: 

Here's the on-disk format. The pid field is a 4-byte int, like pid_t. The instance ID is specified to be a string. If you chase it through the Flatpak code it turns out to actually be a guint32 picked by g_random_int() but I don't want to rely on implementation details. Turns out an app can determine the real host PID of its bwrap process by reading /run/user/1001/.flatpak/$INSTANCE_ID/pid which feels like half the battle, but that doesn't help when checking if the other instance is still running.

Turns out all the checks for the b0_pid field are guarded with a != 0L check so maybe it could just be zeroed. But it is useful to be prevented from opening the same file twice.

[debarshiray]

Turns out an app can determine the real host PID of its bwrap process
by reading /run/user/1001/.flatpak/$INSTANCE_ID/pid which feels like
half the battle, but that doesn't help when checking if the other instance
is still running.

Oh, yes, this isn't just about the application process identifying itself. We also need to find out if there's any other process around matching the same identifier.

Can we do the unthinkable and disable the PID namespace for Vim? :)

The other application where I have come across this problem is Darktable, which also uses lock files containing the PID to gate access to the various databases. Unlike Vim, where being single-instance isn't trivial, I don't see why Darktable can't use D-Bus to ensure uniqueness. I see that it already claims org.darktable.service, but it neither implements org.freedesktop.Application nor org.gtk.Application. I don't know what's going on there.

[wjt]

On Wed, 3 Jul 2019, at 02:56, Debarshi Ray wrote: Oh, yes, this isn't just about the application process identifying itself. We also need to find if there's any other process around matching the same identifier. Can we do the unthinkable and disable the PID namespace for Vim? :)

This seems a little heavy-handed! :) How about making it so running the Vim Flatpak a second time reuses the sandboxes from the first, still-running instance? Not sure how hard this would be – `flatpak enter` can manage it though.

The other application where I have come across this problem is Darktable, which also uses lock files containing the PID to gate access to the various databases. Unlike Vim, where being single-instance isn't trivial,

Well, Vim actually does provide its own mechanism for something like this (`--remote` and `--serverlist` for reference) but it's a pain to use IME. Maybe one could iterate each server and ask for its instance ID, but… by default, if you run Vim in non-GUI mode it doesn't make itself into a server. (I guess it uses X for IPC.)