I’d like to add that few programs litter the filesystem like this. It is much more common for multi-user systems via ssh to get disconnected and leave a swap. It would make more sense to recreate a temporary directory for this. I’m not so much in for the security, but I believe in retaining the ability to trigger a warning on editing the same file on multi-user - meanwhile avoiding using the whole filesystem and network shares for this unless explicitly enabled. There could be multiple solutions for this and I believe Bram would have a say that could improve this refactoring if it could be done.
On Mon, 6 Nov 2017 at 22.26, Nikolay Aleksandrovich Pavlov < zyx....@gmail.com> wrote: > 2017-11-06 23:33 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>: > > > > Scott Court wrote: > > > >> Those are very valid points, and I agree that the way Neovim handles > >> .swp files is better. I've already explained on here and on Openwall > >> numerous reasons why I believe that is the best solution and made the > >> case that .swp files should be stored in ~/.vim/swap by default. However > >> Bram has veto power and shot that idea down. > >> > >> So instead I'm trying to find the next best way to address this. > >> /var/lib being writable only by root and therefore requiring cooperation > >> from packagers did not occur to me, but that's definitely a problem. > >> Maybe it would be doable as a major change in the next major release of > >> Vim, but you're right; that definitely won't work as a security patch. > >> So much for that idea. > >> > >> I maintain a Linux Distribution (Cucumber Linux) and have already > >> adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just > >> have to hope that other distributions independently start doing > >> something similar, as Bram seems pretty convinced this problem is > >> completely a user error and has nothing to do with the way Vim works; > >> he's also pretty set on not changing the default .swp location. > > > > There are a few situations you need to consider: > > - Removable media, editing a file on a USB stick. > > - Remote file systems (where the mount point may change over time). > > - Multiple users editing a shared file. > > - Renaming directories. > > > > There are likely many more > > - Remote file systems is a case *against* using swap files in the > current directory, should they be slow Vim starts being unresponsive > when it does something with swap file. > - Removable media is a case against swap files as well: while nowadays > you are unlikely to exhaust write cycles or cause unresponsiveness by > using swap files there, there are still considerations like > > 1. Whether “user saved and removed the media without properly > closing the editor or wiping out buffer” is less common scenario then > “user removed the media without …, but did not save and now wants to > restore on another machine”. Swap files there are welcome only if > second scenario is more common, but there is a second point as well. > 2. Removable media is also commonly used for sharing not between > computers belonging to one user, but between computers belonging to > different users. Swap files would be nothing other then annoying > garbage when shared with a user not using *Vim and either using > Windows (i.e. OS which does not hide dotfiles) or having his file > manager configured to show hidden files. Also if files with swap files > nearby were edited on such a machine trying to restore something from > them will do more harm then good. > > - Swap files are utterly useless for preventing editing a single file > by multiple users: way too many conditions need to be true for that to > work: users need to both use *Vim, users need to both have configured > to save swap files in the current directory, users need to pay > attention and not discard the message thinking e.g. that it was an > artifact from previous disconnect. > > Also Vim does not provide any way to do anything sensible with the > situation “two users simultaneously edit the same file”. False > positives and negatives do not make the situation better as well: > neither Vim checks whether currently running process with PID stored > in swap file has anything to do with the creator of swap files, nor > there is any way to determine whether simultaneous editing actually > happens in “remote file system with access from different machines” > and “access from same machine, but separated via various means like > PID namespaces” cases. Enough false alarms and users will stop caring > about them. > > - Yet another case *against* the idea of `set directory=.`: consider > the simple script which simulates renaming directory without closing > the file: > > mkdir test-br.d > #vim -u NONE -i NONE -N \ > # test-br.d/file \ > # -c write -c '!mv test-br.d test-ar.d' \ > # -c 'file test-ar.d/file' \ > vim -u NONE -i NONE -N \ > test-br.d/file \ > -c write \ > -c '!mv test-br.d test-ar.d' \ > -c 'bw' \ > -c 'edit test-ar.d/file' > > What will you see in both commented and uncommented cases? Right, > E325: ATTENTION! Is there any value in seeing it? No, file was already > saved, PID belongs to the same Vim instance, but, unfortunately, you > can’t delete that swap file from Vim menu for Vim process being > “already running”. But should you have > > rm -rf test-br?.d > mkdir test-br.d > mkdir test-swap.d > vim -u NONE -i NONE -N \ > --cmd 'let &directory=getcwd()."/test-swap.d//"' \ > test-br.d/file \ > -c write \ > -c '!mv test-br.d test-ar.d' \ > -c 'bw' \ > -c 'edit test-ar.d/file' > > and Vim automatically and correctly deletes the no-longer-needed > swap file attached to the previous location of the file. > > > > > > -- > > FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing. > > > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net > \\\ > > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ > \\\ > > \\\ an exciting new programming language -- http://www.Zimbu.org > /// > > \\\ help me help AIDS victims -- http://ICCF-Holland.org > /// > > > > -- > > -- > > 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. > > -- > -- > 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 a topic in the > Google Groups "vim_dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/vim_dev/sRT9BtjLWMk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Best Regards/Venlig Hilsen Christoffer Aasted -- -- 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.
