73179Re: incorrect "still running" swap file message
- Sep 11 4:04 PM
On Sep 12, 2013 2:57 AM, "Tony Mechelynck" <antoine.mechelynck@...> wrote:
> On 11/09/13 22:31, Andrew McNabb wrote:
>> Vim (vim-enhanced-7.4.0-2.fc19.x86_64 on Fedora) is currently reporting
>> 'Found a swap file by the name ".linalg.py.swp"' along with
>> 'process ID: 4157 (still running)'.
>> However, process 4157 is not a Vim process:
>> $ readlink /proc/4157/exe
>> /usr/bin/pulseaudio (deleted)
>> and '.linalg.py.swp' does not appear in /proc/4157/fd.
>> Unfortunately, since Vim thinks that another process is using the swap
>> file, it does not give a '(D)elete' option to remove the outdated swap
>> file. It would be nice if either the heuristic for determining whether
>> another Vim process would use information in /proc.
> Yeah, Vim's logic to find out if the owner of a swapfile is "still running" is rather elementary: all it sees in the swapfile is a process number, and if there is a process by that number (which, as you saw, might be a different process) presently running, the "still running" message appears.
> In this case Vim could be said to be "too prudent": in case of doubt it prefers to leave a swapfile lying around than to remove one which might be in use. If it checked the process name, that wouldn't work against the case when Vim would be running under a different name, e.g. vim, gvim, gvimdiff, vi, ex, etc. As the last of these examples shows, it's even perfectly possible to run Vim under a name not even containing the letters "vi". In fact, you could be running a "custom Vim" under any name at all (any name acceptable as an executable filename I mean) and it would still edit your files with no problem.
I would just save all the necessary information in the swap file: command-line arguments and process name in addition to PID.
> In this case the process with the same process name has had its executable "deleted under it". Restart pulseaudio and it won't even use the same executable (it's probably been the object of a software update since the latest reboot).
> And, yes, it would indeed be nice to use the information in /proc; but don't forget that that would definitely not apply to Windows systems, I'm not sure if it would apply to Mac OS X systems, and IIUC it is even quite possible (though I daresay unusual except during boot and shutdown) to run a Linux system with no mounted /proc filesystem. I'm not sure if /proc is mounted when you boot a Linux system into "single-user" emergency-repairs mode, but that is certainly one of the times when Vim is useful (or at least a bare-bones "tiny" Vim, since in that case X11 isn't started and /usr/local might be on a filesystem not mounted).
It would be logical that vim should report that swap file is being used once it cannot determine process properties. When /proc is not mounted you do not get garbage process properties: you get no properties at all.
> Best regards,
> default, n.:
> [Possibly from Black English "De fault wid dis system is you,
> mon."] The vain attempt to avoid errors by inactivity. "Nothing will
> come of nothing: speak again." -- King Lear.
> -- Stan Kelly-Bootle, "The Devil's DP Dictionary"
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
> --- You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
> For more options, visit https://groups.google.com/groups/opt_out.
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.
- << Previous post in topic Next post in topic >>