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.
/// Bram Moolenaar -- Br...@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 ///
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.
Sounds like a TODO item.
Craig
> 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.
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.
> 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>
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.
I'd like to test, but currently the only computers I use are stuck onWindows 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.
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.
2012/08/23 Thu 4:29:47 UTC+9 Ian Halliday:
> 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.
Best regards,
Ken Takata
2012/08/25 Sat 12:41:45 UTC+9 Ken Takata:
> 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.
Best regards,
Ken Takata