Update: I just read through the Filesystem Hierarchy Standard more carefully, and it appears there actually is a directory for this purpose: /var/lib in which the FHS states we can create a /var/lib/vim/swap subdirectory in for this purpose.
From http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBLTEDITORGTEDITORBACKUPFILESAN > > /var/lib/<editor> : Editor backup files and state (optional) > > > Purpose > > These directories contain saved files generated by any unexpected > termination of an editor (e.g., *elvis*, *jove*, *nvi*). > > Other editors may not require a directory for crash-recovery files, > but may require a well-defined place to store other information while > the editor is running. This information should be stored in a > subdirectory under /var/lib (for example, GNU Emacs would place lock > files in /var/lib/emacs/lock). > Maybe we should store the .swp files there. On 11/06/2017 12:29 PM, Scott Court wrote: > The problem with storing the .swp tiles in /tmp though is that (on most > distributions) /tmp gets cleared on every reboot, which is a problem > since one of the major purposes of .swp files is to allow recovery of a > vim session after system crash/hard reboot. > > Also, the default Apache httpd config does permit serving of . (dot) files. > > Perhaps we should store the swap files in a sticky directory visible by > all users that is a) not ever going to be on a **shared** NFS and b) not > going to be cleared on reboot (say /var/cache/vim/swap), and then set > the permissions for all .swp files to 0600. > > It's also not really reasonable to expect every user of Vim to be aware > of every potential security vulnerability and edit his configuration > files to protect against them. See the first paragraph of the "Secure by > Default" section at https://www.openbsd.org/security.html. > > > On 11/06/2017 11:29 AM, dezz...@gmail.com wrote: >> On Tuesday, October 31, 2017 at 3:11:55 PM UTC+1, Christian Brabandt wrote: >>> It is true, that this can cause a problem. However, I am not sure its >>> correct to blame vim here. >>> First, I think you need to configure your webserver to be able to view >>> dotfiles. I believe a default installation of at least apache won't let >>> you show dotfiles. Second, I wonder why those swapfiles are not deleted. >>> Somehow Vim must have crashed or be killed and in that case one >>> certainly don't want that the swapfiles are deleted (think of recovery). >> I agree. Although a multi-user system usually is connected via ssh - in that >> same scenario sometimes the connection is interrupted or people are on flaky >> wifi. This leaves ~ swapfiles littered over the system more frequently as a >> multi-user system over ssh. Which gives more reason to not litter the >> current directory for multi-user environments even with the argument of >> people editing the same file. Most people are annoyed by littered files over >> a filesystem. >> >>> One could argue, that swap files should be stored below ~/.vim directory >>> tree. But what if several users edit the same file? One also needs to >>> make sure, the path would be encoded into the name, but then we might >>> run into trouble with filename length limitations. >> A shared directory in /tmp for all vim instances on a multi-user system >> would solve the issue while not littering the filesystem. >> >>> So I think it in the users responsibility to configure Vim correctly >>> (check the directory option) to not have him litter his document root >>> with old swap files. >> Almost every .vimrc I've ever read had a line to set directory to exclude >> current directory and it is more an annoyance than a feature when countless >> people are asking this question over and over again what filename~ files >> are. I agree vim should be geared towards multi-user systems as well and >> warn when appropriate. It just makes more sense to have it in $TMP in that >> case and retain that behaviour. >> > -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
