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 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.
