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. What you apparently are doing (securing individual files in your home directory) sounds very unusual. The normal way is that the whole home directory of a user is secure/safe. And then perhaps making an exception for some files (e.g. a large video) by symlinking to another disk. Only securing individual files is not secure, in my opinion, since you never know what files an application are going to create, assuming that the home directory is safe/secure, which is the normal situation. E.g. what if a new version of the shell decides to rename the history file? -- "You're fired." (1980) "You're laid off." (1985) "You're downsized." (1990) "You're rightsized." (1992) (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- [email protected] -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201910251317.x9PDHTn4024721%40masaka.moolenaar.net.
