:help 'backupcopy' indicates that the default value of "auto" should
Do The Right Thing when the file is really a symbolic link:
The "auto" value is the middle way: When Vim sees that renaming file
is possible without side effects (the attributes can be passed on and
the file is not a link) that is used. When problems are expected, a
copy will be made.
I confirm that my 'backupcopy' is set to "auto", but when writing to a
symbolic link in Windows Vista, the link gets destroyed.
The following "fixes" the problem:
" for some reason, backupcopy=auto doesn't work on Windows to keep
" symbolic links. I use these in my vimfiles directory to override
some
" runtime files which I really edit in the vim source repository.
autocmd BufWritePre ~/vimfiles/* set backupcopy=yes
autocmd BufWritePost ~/vimfiles/* set backupcopy&
I don't think this ought to be necessary. Am I missing something? If
not, this looks like a bug. But, I cannot imagine I'm the first person
to notice this.
Note, I was lead to this solution (in a roundabout way) from here:
Ben Fritz wrote: > :help 'backupcopy' indicates that the default value of "auto" should > Do The Right Thing when the file is really a symbolic link:
> The "auto" value is the middle way: When Vim sees that renaming file > is possible without side effects (the attributes can be passed on and > the file is not a link) that is used. When problems are expected, a > copy will be made.
> I confirm that my 'backupcopy' is set to "auto", but when writing to a > symbolic link in Windows Vista, the link gets destroyed.
> The following "fixes" the problem:
> " for some reason, backupcopy=auto doesn't work on Windows to keep > " symbolic links. I use these in my vimfiles directory to override > some > " runtime files which I really edit in the vim source repository. > autocmd BufWritePre ~/vimfiles/* set backupcopy=yes > autocmd BufWritePost ~/vimfiles/* set backupcopy&
> I don't think this ought to be necessary. Am I missing something? If > not, this looks like a bug. But, I cannot imagine I'm the first person > to notice this.
> Note, I was lead to this solution (in a roundabout way) from here:
There is the mch_is_linked() function which is supposed to detect links on a file. I don't know why it doesn't work in this situation. Are you using a recent version of Vim?
-- hundred-and-one symptoms of being an internet addict: 253. You wait for a slow loading web page before going to the toilet.
On Thu, Jul 7, 2011 at 6:34 AM, Bram Moolenaar <B...@moolenaar.net> wrote:
> Ben Fritz wrote:
>> :help 'backupcopy' indicates that the default value of "auto" should >> Do The Right Thing when the file is really a symbolic link:
>> The "auto" value is the middle way: When Vim sees that renaming file >> is possible without side effects (the attributes can be passed on and >> the file is not a link) that is used. When problems are expected, a >> copy will be made.
>> I confirm that my 'backupcopy' is set to "auto", but when writing to a >> symbolic link in Windows Vista, the link gets destroyed.
>> The following "fixes" the problem:
>> " for some reason, backupcopy=auto doesn't work on Windows to keep >> " symbolic links. I use these in my vimfiles directory to override >> some >> " runtime files which I really edit in the vim source repository. >> autocmd BufWritePre ~/vimfiles/* set backupcopy=yes >> autocmd BufWritePost ~/vimfiles/* set backupcopy&
>> I don't think this ought to be necessary. Am I missing something? If >> not, this looks like a bug. But, I cannot imagine I'm the first person >> to notice this.
>> Note, I was lead to this solution (in a roundabout way) from here:
> There is the mch_is_linked() function which is supposed to detect links > on a file. I don't know why it doesn't work in this situation. Are you > using a recent version of Vim?
Yes, the "Vim without Cream" install for 7.3.206. I'm not running as administrator, but required admin access to create the links. That doesn't affect anything, does it? I can try again from the admin account later if it might.
> -----Original Message----- > From: vim_dev@googlegroups.com [mailto:vim_dev@googlegroups.com] On > Behalf Of Benjamin Fritz > Sent: Thursday, July 07, 2011 8:02 AM > To: Bram Moolenaar > Cc: vim_dev > Subject: Re: 'backupcopy' and Windows Vista symbolic links
> On Thu, Jul 7, 2011 at 6:34 AM, Bram Moolenaar <B...@moolenaar.net> > wrote:
> > Ben Fritz wrote:
> >> :help 'backupcopy' indicates that the default value of "auto" should > >> Do The Right Thing when the file is really a symbolic link:
> >> The "auto" value is the middle way: When Vim sees that renaming > >> file > >> is possible without side effects (the attributes can be passed > >> on and > >> the file is not a link) that is used. When problems are > >> expected, a > >> copy will be made.
> >> I confirm that my 'backupcopy' is set to "auto", but when writing to > >> a symbolic link in Windows Vista, the link gets destroyed.
> >> The following "fixes" the problem:
> >> " for some reason, backupcopy=auto doesn't work on Windows to > >> keep > >> " symbolic links. I use these in my vimfiles directory to > >> override some > >> " runtime files which I really edit in the vim source repository. > >> autocmd BufWritePre ~/vimfiles/* set backupcopy=yes > >> autocmd BufWritePost ~/vimfiles/* set backupcopy&
> >> I don't think this ought to be necessary. Am I missing something? If > >> not, this looks like a bug. But, I cannot imagine I'm the first > >> person to notice this.
> >> Note, I was lead to this solution (in a roundabout way) from here:
> > There is the mch_is_linked() function which is supposed to detect > > links on a file. I don't know why it doesn't work in this situation. > > Are you using a recent version of Vim?
> Yes, the "Vim without Cream" install for 7.3.206. I'm not running as > administrator, but required admin access to create the links. That doesn't affect > anything, does it? I can try again from the admin account later if it might.
The mch_is_linked() function in os_win32.c only checks if there is more than one hard link (i.e. name) for the file. It doesn't check if the file is a symbolic link. By contrast the Unix code does check if the file is a symbolic link.
On Wednesday, July 20, 2011 3:54:09 PM UTC-4, Craig Barkhouse wrote: > The mch_is_linked() function in os_win32.c only checks if there is more than one hard link (i.e. name) for the file. It doesn't check if the file is a symbolic link. By contrast the Unix code does check if the file is a symbolic link.
> Sounds like a TODO item.
Hello all, did this ever get turned into a TODO item? I've encountered this myself (I'm syncing all my vim configuration across machines using Dropbox, with symbolic links for .vim/, .vimrc, and .gvimrc).
I see in the latest Mercurial code that mch_is_linked() still only checks for hard links. If it's not already in someone's TODO bucket I can work on a fix. The APIs are straightforward in the versions of Windows that support symlinks; I suspect more of the work will be in figuring out how to get that support into vim without breaking binary compatibility on older systems. Would the maintainers be interested in seeing a patch for this?
David Pope wrote: > On Wednesday, July 20, 2011 3:54:09 PM UTC-4, Craig Barkhouse wrote:
> > The mch_is_linked() function in os_win32.c only checks if there is > > more than one hard link (i.e. name) for the file. It doesn't check > > if the file is a symbolic link. By contrast the Unix code does > > check if the file is a symbolic link.
> > Sounds like a TODO item.
> Hello all, did this ever get turned into a TODO item? I've > encountered this myself (I'm syncing all my vim configuration across > machines using Dropbox, with symbolic links for .vim/, .vimrc, and > .gvimrc).
> I see in the latest Mercurial code that mch_is_linked() still only > checks for hard links. If it's not already in someone's TODO bucket I > can work on a fix. The APIs are straightforward in the versions of > Windows that support symlinks; I suspect more of the work will be in > figuring out how to get that support into vim without breaking binary > compatibility on older systems. Would the maintainers be interested > in seeing a patch for this?
A patch definitely helps. And a way to reproduce the problem.
-- hundred-and-one symptoms of being an internet addict: 194. Your business cards contain your e-mail and home page address.
On Thu, Mar 15, 2012 at 2:28 PM, Bram Moolenaar <B...@moolenaar.net> wrote:
> David Pope wrote:
>> On Wednesday, July 20, 2011 3:54:09 PM UTC-4, Craig Barkhouse wrote:
>> > The mch_is_linked() function in os_win32.c only checks if there is >> > more than one hard link (i.e. name) for the file. It doesn't check >> > if the file is a symbolic link. By contrast the Unix code does >> > check if the file is a symbolic link.
>> > Sounds like a TODO item.
>> Hello all, did this ever get turned into a TODO item? I've >> encountered this myself (I'm syncing all my vim configuration across >> machines using Dropbox, with symbolic links for .vim/, .vimrc, and >> .gvimrc).
>> I see in the latest Mercurial code that mch_is_linked() still only >> checks for hard links. If it's not already in someone's TODO bucket I >> can work on a fix. The APIs are straightforward in the versions of >> Windows that support symlinks; I suspect more of the work will be in >> figuring out how to get that support into vim without breaking binary >> compatibility on older systems. Would the maintainers be interested >> in seeing a patch for this?
> A patch definitely helps. And a way to reproduce the problem.
Reproduction is easy.
1. Create a symbolic link on Windows. (e.g. mklink link_path target_path) 2. open the file in Vim 3. write the file from Vim
The symbolic link has been destroyed, now it's a "real" file separate from the file it was originally linked to.
> On Thu, Mar 15, 2012 at 2:28 PM, Bram Moolenaar <B...@moolenaar.net> > wrote:
> > David Pope wrote:
> >> On Wednesday, July 20, 2011 3:54:09 PM UTC-4, Craig Barkhouse wrote:
> >> > The mch_is_linked() function in os_win32.c only checks if there is > >> > more than one hard link (i.e. name) for the file. It doesn't check > >> > if the file is a symbolic link. By contrast the Unix code does > >> > check if the file is a symbolic link.
> >> > Sounds like a TODO item.
> >> Hello all, did this ever get turned into a TODO item? I've > >> encountered this myself (I'm syncing all my vim configuration across > >> machines using Dropbox, with symbolic links for .vim/, .vimrc, and > >> .gvimrc).
> >> I see in the latest Mercurial code that mch_is_linked() still only > >> checks for hard links. If it's not already in someone's TODO bucket I > >> can work on a fix. The APIs are straightforward in the versions of > >> Windows that support symlinks; I suspect more of the work will be in > >> figuring out how to get that support into vim without breaking binary > >> compatibility on older systems. Would the maintainers be interested > >> in seeing a patch for this?
> > A patch definitely helps. And a way to reproduce the problem.
> Reproduction is easy.
> 1. Create a symbolic link on Windows. (e.g. mklink link_path target_path) > 2. open the file in Vim > 3. write the file from Vim
> The symbolic link has been destroyed, now it's a "real" file separate > from the file it was originally linked to.
Here's my first shot at a patch that fixes the "can't save to symlinks" bug on Windows. It augments the Windows version of mch_is_linked() to also return TRUE if the file is a symbolic link, so the delete-then-move pattern is avoided and the symlink is preserved.
The patch also addresses a separate bug I encountered while fixing the above. If you set nowritebackup on Windows, and then save a file that you opened via a symbolic link, the readonly attribute gets set.
The cause was that the Windows version of mch_getperm() was returning Windows FILE_ATTRIBUTE_* flags instead of the Unix-style flags in mode_t, which was then later passed unchanged to the CRT open() function (which expects mode_t flags).
For a normal (non-symlink, non-whatever) file, this just happened to be FILE_ATTRIBUTE_NORMAL (0200, 0x80), which maps to the Unix S_IWUSR. By sheer chance, this meant that normal files correctly received write permission, i.e. no readonly flag.
For a symlink, FILE_ATTRIBUTE_NORMAL is not set; for example, the symlink I was testing against returned FILE_ATTRIBUTE_ARCHIVE (040, 0x20) and FILE_ATTRIBUTE_REPARSE_POINT (02000, 0x400). By the time these made it back to create(), it appeared as though we wanted no write permissions, i.e. set the readonly flag.
The patch changes os_win32.c so that all code outside of the file deals with mode_t flags, while os_win32.c itself deals with FILE_ATTRIBUTE_* flags. There are a couple of new internal helper functions for this.
This is my first patch, so I'm sure I messed up somewhere; feedback is welcome. Sorry if the above is too wordy, this was a fun one to diagnose. ;)
Caveats: * I have no way to test Win98, can someone help? There is lots of Win98 fallback code in os_win32.c (to use non-Unicode functions when FEAT_MBYTE is defined). * I added win32_* signatures to os_win32.pro for the new internal functions; I'm not sure if the *.pro files are intended mainly for function exports, or just to avoid having to make forward declarations (as I've done here). * I'm using a couple of CRT functions that weren't in use before; I don't know if it's reasonable to assume that they work as expected on all the old platforms that are required.
On Wed, Mar 21, 2012 at 2:27 AM, David Pope <d.e.p...@gmail.com> wrote: > > A patch definitely helps. And a way to reproduce the problem.
>> Reproduction is easy.
>> 1. Create a symbolic link on Windows. (e.g. mklink link_path target_path) >> 2. open the file in Vim >> 3. write the file from Vim
>> The symbolic link has been destroyed, now it's a "real" file separate >> from the file it was originally linked to.
> Here's my first shot at a patch that fixes the "can't save to symlinks" > bug on Windows.
<snip>
Is there any feedback on this patch, or on the way the fix was presented? As I said earlier, I'm new to vim development so I'm all ears. :) Is there someone I need to direct this patch toward, e.g. someone who deals primarily with the Windows version of vim, to get it vetted/updated for mainline inclusion?
On Fri, Mar 23, 2012 at 11:35 PM, David Pope <d.e.p...@gmail.com> wrote:
> Is there any feedback on this patch, or on the way the fix was presented? > As I said earlier, I'm new to vim development so I'm all ears. :) Is > there someone I need to direct this patch toward, e.g. someone who deals > primarily with the Windows version of vim, to get it vetted/updated for > mainline inclusion?
I'd like to test, but currently the only computers I use are stuck on Windows XP and I'm not able to. The machine I was using at the time I originally encountered the issue was a dual-boot Windows Vista/Ubuntu machine, which now has a bad motherboard.
On Mon, Mar 26, 2012 at 11:00 AM, Benjamin Fritz <fritzophre...@gmail.com>wrote:
> I'd like to test, but currently the only computers I use are stuck on > Windows XP and I'm not able to. The machine I was using at the time I > originally encountered the issue was a dual-boot Windows Vista/Ubuntu > machine, which now has a bad motherboard.
Thanks, any help is appreciated. I have updated the patch with some further fixes (it broke a common pattern for calling mch_getperms to check for file existence). The latest patch is available in my fork at github: https://code.google.com/r/depope-vim/ . Should I continue posting patches here in vim_dev or is github considered better?
On Thursday, March 29, 2012 12:52:49 AM UTC-5, David Pope wrote:
> Thanks, any help is appreciated. I have updated the patch with some further > fixes (it broke a common pattern for calling mch_getperms to check for file > existence). The latest patch is available in my fork at github: > https://code.google.<WBR>com/r/depope-vim/ . Should I continue posting > patches here in vim_dev or is github considered better?
That's not github, by the way :-)
It can be nice to pull from a real repository, but some people (me included) would prefer to put experimental patches into a patch queue with mq. I like this option better because Bram doesn't pull from clones, he just uses the patches (or at least this is the case for the "official" repository, obviously I don't know what his personal clones might look like). So, if I pull a bunch of changes on the default branch into my clone, that history never gets pulled in and either I will need to strip it or let some extra head just dangle.
So if you want to commit to a clone, that's good, and you should share it...but certainly continue posting patches on vim_dev. I wonder if there's a good way to share patch queues related to a project? That might be an even better way.
On Thu, Mar 29, 2012 at 10:30 AM, Ben Fritz <fritzophre...@gmail.com> wrote:
> That's not github, by the way :-)
oops :)
> It can be nice to pull from a real repository, but some people (me > included) would prefer to put experimental patches into a patch queue with > mq. I like this option better because Bram doesn't pull from clones, he > just uses the patches (or at least this is the case for the "official" > repository, obviously I don't know what his personal clones might look > like). So, if I pull a bunch of changes on the default branch into my > clone, that history never gets pulled in and either I will need to strip it > or let some extra head just dangle.
So if you want to commit to a clone, that's good, and you should share
> it...but certainly continue posting patches on vim_dev. I wonder if there's > a good way to share patch queues related to a project? That might be an > even better way.
Good point; I haven't used the mq extension before, so I'll go figure it out, along with its implied workflows. I'll probably have questions after that. ;)
I just ran into this problem for a second time in the last year, having forgotten how to fix it since last time, had to look everything up again. A fix in the main branch would be great to have.
> I just ran into this problem for a second time in the last year, having forgotten how to fix it since last time, had to look everything up again. A fix in the main branch would be great to have.
Good timing. I also found this problem a few days ago. I tried to write my own patch but it didn't work well. :-<
Then I found your post and tried David's patch. It seems that the patch works well but I found a little problem. This is an updated patch. https://gist.github.com/3436380
The differences from David's patch are: 1. Fix memory leakage in win32_file_is_symbolic_link(). 2. Use mch_stat() to implement mch_getperm(). (His implementation on Google Code does not support multibyte characters.) 3. Add support for "breakhardlink" and "breaksymlink". 4. Change the name of some functions.
> Then I found your post and tried David's patch. > It seems that the patch works well but I found a little problem. > This is an updated patch. > https://gist.github.com/3436380
> The differences from David's patch are: > 1. Fix memory leakage in win32_file_is_symbolic_link(). > 2. Use mch_stat() to implement mch_getperm(). > (His implementation on Google Code does not support multibyte characters.) > 3. Add support for "breakhardlink" and "breaksymlink". > 4. Change the name of some functions.
I have updated the patch.
1. fix mch_remove() to support multibyte file name again. 2. fix return value of win32_setattrs(). 3. add some comments.
