Loading ...
Sorry, an error occurred while loading the content.
 

Re: 'backupcopy' and Windows Vista symbolic links

Expand Messages
  • Bram Moolenaar
    ... 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
    Message 1 of 16 , Jul 7, 2011
      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:
      >
      > http://superuser.com/questions/193872/vim-destroys-symbolic-links-under-windows

      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 -- Bram@... -- 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
    • Benjamin Fritz
      ... 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
      Message 2 of 16 , Jul 7, 2011
        On Thu, Jul 7, 2011 at 6:34 AM, Bram Moolenaar <Bram@...> 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:
        >>
        >> http://superuser.com/questions/193872/vim-destroys-symbolic-links-under-windows
        >
        > 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.

        --
        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
      • Craig Barkhouse
        ... 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
        Message 3 of 16 , Jul 20, 2011
          > -----Original Message-----
          > From: vim_dev@... [mailto:vim_dev@...] 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 <Bram@...>
          > 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:
          > >>
          > >> http://superuser.com/questions/193872/vim-destroys-symbolic-links-und
          > >> er-windows
          > >
          > > 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.

          Sounds like a TODO item.

          Craig

          --
          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
        • David Pope
          ... 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,
          Message 4 of 16 , Mar 14, 2012
            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?

            --
            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
          • Bram Moolenaar
            ... 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
            Message 5 of 16 , Mar 15, 2012
              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.

              /// Bram Moolenaar -- Bram@... -- 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
            • Benjamin Fritz
              ... 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
              Message 6 of 16 , Mar 15, 2012
                On Thu, Mar 15, 2012 at 2:28 PM, Bram Moolenaar <Bram@...> 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.

                --
                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
              • David Pope
                ... 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
                Message 7 of 16 , Mar 20, 2012
                  On Thu, Mar 15, 2012 at 5:02 PM, Benjamin Fritz <fritzophrenic@...> wrote:
                  On Thu, Mar 15, 2012 at 2:28 PM, Bram Moolenaar <Bram@...> 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.

                  ----
                  David Pope

                  --
                  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
                • David Pope
                  Hello Bram, Benjamin, and all, ... ... Is there any feedback on this patch, or on the way the fix was presented? As I said earlier, I m new to vim
                  Message 8 of 16 , Mar 23, 2012
                    Hello Bram, Benjamin, and all,

                    On Wed, Mar 21, 2012 at 2:27 AM, David Pope <d.e.pope@...> 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?

                    Thanks,
                    ----
                    David Pope

                    --
                    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
                  • Benjamin Fritz
                    ... 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
                    Message 9 of 16 , Mar 26, 2012
                      On Fri, Mar 23, 2012 at 11:35 PM, David Pope <d.e.pope@...> 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.

                      --
                      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
                    • David Pope
                      ... 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
                      Message 10 of 16 , Mar 28, 2012
                        On Mon, Mar 26, 2012 at 11:00 AM, Benjamin Fritz <fritzophrenic@...> 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?

                        -- Dave

                        --
                        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
                      • Ben Fritz
                        ... 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
                        Message 11 of 16 , Mar 29, 2012
                          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.

                          --
                          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
                        • David Pope
                          ... oops :) ... So if you want to commit to a clone, that s good, and you should share ... Good point; I haven t used the mq extension before, so I ll go
                          Message 12 of 16 , Mar 29, 2012
                            On Thu, Mar 29, 2012 at 10:30 AM, Ben Fritz <fritzophrenic@...> 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.  ;)
                             
                            Thanks,
                            -- Dave

                            --
                            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
                          • Ian Halliday
                            What ever happened to this patch? 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
                            Message 13 of 16 , Aug 22, 2012
                              What ever happened to this patch?

                              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.

                              Ian

                              --
                              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
                            • Ken Takata
                              Hi, ... Good timing. I also found this problem a few days ago. I tried to write my own patch but it didn t work well. :-
                              Message 14 of 16 , Aug 24, 2012
                                Hi,

                                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

                                --
                                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
                              • Ken Takata
                                Hi, ... 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
                                Message 15 of 16 , Sep 24, 2012
                                  Hi,

                                  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

                                  --
                                  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
                                Your message has been successfully submitted and would be delivered to recipients shortly.