2017-11-07 1:27 GMT+03:00 Christoffer Aasted <chr.aas...@gmail.com>: > 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.
Well, you got a warning and now what? Warning itself is useless without a plan for handling the issue. Could you at least first write an exact plan how *you* are going to handle the situation in your specific case? Then imagine that you want to extend `:h E325` with a more useful and multi-user-environment-adapted advice then just “you must find out what the situation is yourself”. I guess that would include, at least, `ps` and somehow determining the machine identifier (e.g. IP or internal hostname) of whoever connected to a ssh (because in some cases different people may not have dedicated users and instead connect using a single one); then somehow connecting `ps` output (likely user name) or machine identifier with some kind of communication channel. And lots of if’s covering permission issues. One should also not forget that advice will probably start with “open another shell” or “copy the information and press Q”: user may want to retain data displayed with E325 to e.g. start checking the process ID, but Vim is rather unfriendly here, this data is not even in `:messages` and `<C-z>` does not work. Also you should not forget one thing: if you have E325 then some other user *may* be editing the same file you are editing. But both it is *may*, and the opposite is absolutely not true: there are lots of cases when other user is editing the same file as you, but you do not get a warning because he - is not using Vim; - prefers to use scp://; - has different &directory setting; - … This means that unless you have an agreement with all your collegues to use Vim in a set way the mechanizm is absolutely unreliable and thus better be not used for the purpose to not make you have a feeling of the false safety. On the other hand if you *do* have an agreement you *don’t* need to rely on Vim defaults: just also agree e.g. that some &directory value will be set in /etc/vimrc and must not be overridden by vimrc, it is also not impossible to create autocommands which will check following that agreement automatically. > > 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. -- -- 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.
