2017-11-06 20:39 GMT+03:00 Scott Court <[email protected]>: > 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.
That needs active support from package maintainers: on my system (Gentoo) /var/lib is writeable only by root and I do not think that is uncommon. So Vim cannot create a directory there on its own when run by a user and it needs to be created by a package when it is installed. And there is still a question regarding what to do on Windows. Neovim has currently chosen to store swap, undo, backup (fallback, first directory is still dot) and view files under $XDG_DATA_HOME/nvim (Windows: $XDG_DATA_HOME is %LOCALAPPDATA%, but suffix is `nvim-data` unlike just `nvim` on *nix because $XDG_CONFIG_HOME is also %LOCALAPPDATA% (our choice and not a standard, XDG does not apply on Windows)). Reasoning (including “why you should not consider ‘preventing simultaneous access’ a valid argument for existence of swap files in a particular location”) may be seen in https://github.com/neovim/neovim/issues/4481. > > > > 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, [email protected] 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
