Hi Christian,
On 25/10/2019 15:59, Christian Brabandt wrote: > On Fr, 25 Okt 2019, Christian Brabandt wrote: > >> On Fr, 25 Okt 2019, Sihera Andre wrote: >> >>> Hello all, >>> >>> The "backupcopy" option does not appear to be working as >>> documented in the version of VIM I have built locally. As the >>> run-time contains online help for the feature I assume that >>> my version of VIM supports it, or does it? >>> >>> Binary: 8.0.1766 >>> Runtime: 8.0.1766 >>> (full information at bottom) >>> >>> This is the age-old chestnut about trying to symbolic link >>> "~/.viminfo" to another directory. The following URL is what >>> appears to be the most recent bug raised on the issue: >>> >>> https://github.com/vim/vim/issues/2506 >>> >>> It was marked as resolved but my experiences beg to differ. >>> These are the situations I am seeing: >>> >>> 1) I have no ".vimrc"; I edit shell script "x"; syntax highlighting >>> is normal; ":set backupcopy" returns "auto"; I cursor around >>> in file; I exit file; ".viminfo" is written as a regular file with >>> lastediting position in "x". >>> >>> 2) I copy "~/.viminfo" to "~/temp/.viminfo" and symbolic link >>> "~/.viminfo" to "~/temp/.viminfo"; I have no ".vimrc"; I edit >>> script file "x"; syntax highlighting is normal; "set backupcopy" >>> returns "auto"; I enter ":set backupcopy=yes"; I cursoraround >>> in file; I exit file; ".viminfo" is written as a regular filewith >>> last editing position in "x" and the symbolic link vanishes. >>> >>> 3) I copy "~/.viminfo" to "~/temp/.viminfo" and symbolic link >>> "~/.viminfo" to "~/temp/.viminfo"; In the shell I execute >>> "echo 'set backupcopy=yes' >~/.vimrc"; I edit file "x"; all >>> *syntax highlighting disappears* and all text renders in white; >>> ":set backupcopy" returns "yes"; I cursor around in file; I >>> exit file; ".viminfo" is written as a regular file with last >>> editingposition in "x" and the symbolic link vanishes. >>> >>> 4) Setting "backupcopy" to "no" when performing (2) or (3) >>> above has no effect. In this case it performs as documented. >> The backupcopy option tells vim how to handle backup files. I don't >> think it handles how the viminfo file is written. >> >> It does not tell how the actual file is written. Have a look at `:h >> backup-table` for how this interacts. Note for tests, make sure not to >> use a temporary directory, as the `backupskip` option might catch this >> and you might get different results. BTW: I don't understand what you >> mean with >> >> ,---- >> | 3) I copy "~/.viminfo" to "~/temp/.viminfo" and symbolic link >> | "~/.viminfo" to "~/temp/.viminfo"; In the shell I execute >> `---- Strictly speaking, I should have said 'I move "~/.viminfo" to "~/temp"'. Apologies. What I meant was: $ cd ${HOME} $ mkdir temp $ mv .viminfo temp/ $ ln -s temp/.viminfo This "temp" directory is not a system "tmp" directory nor should it be a VIM "tmp" directory. The directory could be anywhere; it should work. > BTW: see also here, why symlinking of the viminfo file does not work: > https://groups.google.com/forum/#!msg/vim_dev/D-gkgoJh3Z4/WnERHnAKfEQJ > > Best, > Christian This is a very thorny issue. For the same reason that you could be subject to a symlink attack (which means that the current policy is good), now the problem is that personal information about what files you've being editing and where are stored in a file that cannot be easily relocated to a secure device (which means the current policy is not fit for purpose). To cut a very long story short, I have being running encrypted home areas (i.e., fully encrypted partitions and swap areas that automatically mount and dismount as you login and logout) for years before major distributions finally thought it was fashionable. However, unlike most systems which typically encrypt the *entire* partition (e.g., all of "/", all of "/home" or all of "/home/<user>"), my system enables all your secure data to be on a separate device and for your home area to symlink all the relevant areas under "/home/<user>", on login, to any configuration of secure devices. This has two major advantages: 1) The default account profile, typically stored under /etc/ which is fixed for every new account created, doesn't have to know it is being set up on an encrypted device. This makes my system portable across all OS distributions. 2) When the OS is upgraded, I detach the encrypted partitions, upgrade OS complete with new, initialised "/", "/home", or "/home/<user>", whatever, then I remount old partition on login and re-link all the secure places under "/home/<user>" as before. Quick, painless, and no incompatibilities. Except that .viminfo, which I would like to relocate to my encrypted partitions, cannot be stored there because it can't be symbolic linked. This, for me, is the security hole. This file is permanently out in the open and it contains all manner of information about my editing history. And that information is increasing with each new major version of ViM. Plus the fact that I don't like being told how to manage my security. Software should be providing all features and setting reasonable defaults; not patronising professionals by trying to "save them from themselves". I think there should be another debate enabling .viminfo to be a symlink and giving computer professionals the ability to manage their own security. Cheers, Andre. -- -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/PSXP216MB0277B68200ED2AAE7ACBA713C0650%40PSXP216MB0277.KORP216.PROD.OUTLOOK.COM.
