2017-11-07 15:46 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>
> Nikolay Pavlov 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.
>
> I don't get this. I use remote file systems all the time, from
> different systems. Having the swap file in the same directory has saved
> my work quite a number of times. Sudden disconnects are the main thing,
> having to go to the file from a different system and use "vim -r". That
> is impossible if the swap file is on a system that became unreachable.
> If the original file becomes unreachable you can't do anything anyway.
>
> On top of that, having the warning that a swap file exists, meaning you
> already changed the file from another system, also often is a life
> saver. Happens for me quite often when working on a test that fails on
> MS-Windows.
>
>> - 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.
>
> That's exactly what happens: you edit a file on a USB stick, do
> something else, have to catch a train, close the laptop without saving,
> take the stick elsewhere, and now your swap file is on a system at home
> while you are at work...
>
>> 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.
>
> That does not match my experience, sounds uncommon to me.
>
>> - 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.
>
> It works very well for me. In multi-user setups it does get more
> tricky, but using your personal store for swap files isn't going to be
> an improvement in any way.
>
> The only situation I'm aware of is when the swap file gets picked up by
> a tool in an unwanted way. E.g. when creating an archive from a
> directory or a version control system that isn't setup to ignore swap
> files. In that case you want to set 'directory', that's what it is for.
How would it help in deleting swap files? Simple test:
```
% mkdir abc
% touch abc/{a,b,c}
% vim -u NONE -i NONE -N --cmd 'set hidden' abc/? -c 'bufdo normal! i'
-c 'set directory=/tmp'
<C-z>
% ls -lA abc
```
How many swap files have Vim deleted from abc? Zero, &directory
changes do not apply for existing buffers with swap files already
assigned.
>
>> 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.
>
> Does not match my experience. Two different users editing the same file
> is very uncommon anyway. In most cases it's the same person working
> from different accounts.
This concern does not completely nullify a point, just makes discovery
of the source of the problem easier and the situation looking more
likely: one user with two accounts or two users with two accounts,
there still is no protocol for the case in documentation and “swap
file exists” warning forces to make a decision right there, without
any checks (like running `ps`) should you forget that you were editing
a file.
Though in place of “should you forget” there is more practical example
of the case which needs investigation before making decision I once
experienced: I knew that previous session crashed, but Vim still
reported it as running: obviously, I got PID collision, but it is not
like I knew the mechanics of such detection at that point.
>
>> - 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.
>
> Yeah, I've been thinking of a way to delete the swap file automatically,
> without the risk of deleting it when it's still needed. Work to be
> done. BTW: this is independent of what 'directory' is set to, the swap
> file will always refer to the original location.
But if &directory is a dedicated directory in the above case Vim
deletes the swap file because buffer name did not change and neither
did location of the swap file. If it is dot original buffer name did
not change, but location of swap file did, so swap file of the
original buffer is considered “lost” (with a warning), and yet it
can’t be deleted from Vim dialogue.
>
> --
> The most powerful force in the universe is gossip.
>
> /// 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 ///
It looks like the main reasoning is “ability to omit saving your work”
in conjunction with “working from a different computers with no easy
access to previously used ones”: without one or the other neither of
your points can make swap files in the current directory useful. My
experience says that while some of my collegues sometimes forget to
save even though they know they do not have UPS and power is known to
flash sometimes, second point is almost non-existent.
And as you said earlier, there *is* &directory setting, nobody is
voicing to remove it, just change the defaults. If dot suits your
workflow better you can set dot, but I very doubt that most Vim users
- do not use archives (or enjoy garbage there),
- do not share files on flash cards with non-Vim users which find swap
files suspicious garbage (just garbage if you explain) (BTW, not
necessary non-*nix users: I once enabled showing hidden files and got
complains about single empty (dolphin configured so it would not leave
anything there) .Trash),
- love to create local .vcsignore files (also not all authors tolerate
swap file ignoring in project .vcsignore and local .vcsignore files
are for some reason less of a common knowledge),
- like to receive swap files in rarely needed `ag --unrestricted` (or
e.g. `grep -a`) output,
- find `ls -lA` output with garbage out there good and
- would not want to be able to create a fast and simple script which
does automatic recovery after a crash: swap files management is easier
if all swap files are in one location.
So far Neovim received almost no complains about the new default.
I have also checked how swap file location makes difference with a
laggy network filesystem (Yandex disk, but mounted with webdav in
place of using their FS synchronizing daemon):
time (vim -u NONE -i NONE -N ~/mnt/yandex/foo --cmd 'set directory=.' -c cq)
reports almost six seconds (5.9),
time (vim -u NONE -i NONE -N ~/mnt/yandex/foo --cmd 'set
directory=~/.vimswap//' -c cq)
reports less then a second (0.7 seconds). `~/mnt/yandex/foo` does not
exist, `~/mnt/yandex` is a wdfs (FUSE) network mount.
---
BTW I have a habit of saving file immediately I pause for a moment to
think for the next action, and for a good reasons: neither all
software I am using bothers with some kind of autosaving or recovery,
nor I find that autosave/recovery being always reliable.
--
--
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.
