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

Cannot overwrite gvimext.dll: access denied

Expand Messages
  • A. J. Mechelynck
    After compiling Vim 7.0aa.0188 (successfully), when trying to copy the result to %VIM% vim70aa and its subdirectories I get (Cygwin cp) cannot delete
    Message 1 of 4 , Jan 26, 2006
      After compiling Vim 7.0aa.0188 (successfully), when trying to copy the
      result to %VIM%\vim70aa and its subdirectories I get

      (Cygwin cp) cannot delete gvimext.dll: Access denied
      (copy, internal to CMD.EXE) Cannot overwrite gvimext.dll: another
      process is using this file.

      Running uninstal doesn't help.

      Rebooting after uninstal _does_ help, but I don't like it. Is there any
      way to mark %VIM%\vim70aa\gvimext.dll as "writable" without rebooting
      (other, I mean, than never setting up the "Edit with Vim" context menus)?


      Best regards,
      Tony.
    • A. J. Mechelynck
      ... The problem with exiting or killing Explorer.exe (I ve done it before, with the help of the Task Manager) is that it s too fundamental to Windows s
      Message 2 of 4 , Jan 26, 2006
        Илья wrote:
        > A. J. Mechelynck wrote:
        >> After compiling Vim 7.0aa.0188 (successfully), when trying to copy the
        >> result to %VIM%\vim70aa and its subdirectories I get
        >>
        >> (Cygwin cp) cannot delete gvimext.dll: Access denied
        >> (copy, internal to CMD.EXE) Cannot overwrite gvimext.dll: another
        >> process is using this file.
        >>
        >> Running uninstal doesn't help.
        >>
        >> Rebooting after uninstal _does_ help, but I don't like it. Is there any
        >> way to mark %VIM%\vim70aa\gvimext.dll as "writable" without rebooting
        >> (other, I mean, than never setting up the "Edit with Vim" context menus)?
        >>
        >>
        >> Best regards,
        >> Tony.
        > gvimext.dll is used by Explorer. You can uninstall it first and then
        > restart Explorer. To restart explorer select Start->Shut down, then hold
        > Ctrl+Shift+Alt and click Cancel. This should cause Explorer to exit. Now
        > press Ctrl+Alt+Del (or Ctrl+Shift+Esc) to run Task Manager, select
        > File->Run, type "explorer" and hit Enter. Now Explorer starts again but
        > without loading gvimext.dll (as reference to it was already removed
        > during uninstallation).
        >
        > Also while developing you may replace gvimext.dll without rebooting
        > using following scenario:
        > 1. Run some kind of file manager or console.
        > 2. Exit Explorer (as described above).
        > 3. Use file manager or console to replace gvimext.dll with new version.
        > 4. Start Explorer again using Task Manager (as described above).
        >
        >
        >

        The problem with exiting or killing Explorer.exe (I've done it before,
        with the help of the Task Manager) is that it's too fundamental to
        Windows's working:

        1. If I kill Explorer.exe, my toolbar, quickstart menu, start menu and
        system tray are killed too until it restarts.

        2. If I kill Explorer.exe (other than by shutting down or rebooting the
        machine), or if it crashes, Windows restarts it without waiting for my
        say-so.

        3. After Explorer restarts, only some (not all) of the icons in my
        system tray (i.e., the small icons near the clock) reappear. The
        programs are still running, but I can't access them anymore. I'm not
        sure what the difference is between the icons that reappear and those
        that don't.

        From my point of view, killing Explorer.exe is even worse than
        rebooting. I'm on Windows XP Home 5.1.2600 SP2.


        Running uninstal.exe makes the "Exit with Vim" menu item disappear from
        the context menus but it doesn't remove the lock on gvimext.dll, as
        noted above.


        Other solutions, anyone?
      • Johnny Blaze
        ... This is what I do... its an exploit on Window s locking mechanism... it locks the file, but not the parent directory... so here is my process ... I have
        Message 3 of 4 , Feb 2, 2006
          On 1/27/06, A. J. Mechelynck <antoine.mechelynck@...> wrote:
          > Илья wrote:
          > > A. J. Mechelynck wrote:
          > >> After compiling Vim 7.0aa.0188 (successfully), when trying to copy the
          > >> result to %VIM%\vim70aa and its subdirectories I get
          > >>
          > >> (Cygwin cp) cannot delete gvimext.dll: Access denied
          > >> (copy, internal to CMD.EXE) Cannot overwrite gvimext.dll: another
          > >> process is using this file.
          > >>
          > >> Running uninstal doesn't help.
          > >>
          > >> Rebooting after uninstal _does_ help, but I don't like it. Is there any
          > >> way to mark %VIM%\vim70aa\gvimext.dll as "writable" without rebooting
          > >> (other, I mean, than never setting up the "Edit with Vim" context menus)?
          > >>
          > >>
          > >> Best regards,
          > >> Tony.

          > Other solutions, anyone?

          This is what I do... its an exploit on Window's locking mechanism...
          it locks the file, but not the parent directory... so here is my
          process ... I have vim installed under c:\vim with
          c:\vim\vim70aa\gvimext.dll

          - cd \vim
          - ren vim70aa old
          - [install new build as vim70aa]
          - [delete everything in old except for gvimext.dll

          Or using the GUI:

          start->run->c:\vim
          [F2 on vim70aa, type old, then enter]
          [double click on old]
          [Ctrl-A, hold Ctrl and click gvimext.dll]
          [Shift-Del, choose Yes]
          [up one folder and extract the vim build]

          If you have multiple builds before you reboot, just keep changing the
          name... old1 old2, etc. Explorer is still using the same gvimext.dll,
          but since there haven't been any changes in gvimext in a long time...
          it doesn't really matter... it still uses the same techniques to find
          gvim.exe.




          --

          . o O pyromancer O o .
        • A. J. Mechelynck
          Johnny Blaze wrote: [...] ... Thanks Johnny. Below is the temporary solution I ve installed, and so much the better for it if gvimext.dll hasn t canged in a
          Message 4 of 4 , Feb 3, 2006
            Johnny Blaze wrote:
            [...]
            > This is what I do... its an exploit on Window's locking mechanism...
            > it locks the file, but not the parent directory... so here is my
            > process ... I have vim installed under c:\vim with
            > c:\vim\vim70aa\gvimext.dll
            >
            > - cd \vim
            > - ren vim70aa old
            > - [install new build as vim70aa]
            > - [delete everything in old except for gvimext.dll
            >
            > Or using the GUI:
            >
            > start->run->c:\vim
            > [F2 on vim70aa, type old, then enter]
            > [double click on old]
            > [Ctrl-A, hold Ctrl and click gvimext.dll]
            > [Shift-Del, choose Yes]
            > [up one folder and extract the vim build]
            >
            > If you have multiple builds before you reboot, just keep changing the
            > name... old1 old2, etc. Explorer is still using the same gvimext.dll,
            > but since there haven't been any changes in gvimext in a long time...
            > it doesn't really matter... it still uses the same techniques to find
            > gvim.exe.
            >
            >
            >
            >
            > --
            >
            > . o O pyromancer O o .


            Thanks Johnny.

            Below is the "temporary solution" I've installed, and so much the better
            for it if gvimext.dll hasn't canged in "a long time"; but first, the
            directories I use:

            I build Vim 7 in "%HOME%\devel\vim\vim70aa"; the compiled (g)vim(d).exe
            programs end up in its "src" subdirectory.

            I have $VIM (or %VIM%) set to "C:\Program Files\vim" (or, actually, to
            "C:\PROGRA~1\vim" without the quotes); Vim 7 sets $VIMRUNTIME to its
            "vim70aa" subdirectory.

            I set up Vim for publishing in "C:\Program Files\vim\pub"; it contains
            only a "vim70aa" subdirectory. (This, in order to have all files in the
            archive listed below a "vim70aa" directory which will be created if
            needed when extracting to $VIM)

            After compiling, I do the following:

            I. Move (but not sources or linkable objects) from "development" to
            "production"

            1. Copy everything recursively from %HOME%\devel\vim\vim70aa\runtime and
            below to %VIM%\vim70aa and below

            2. Copy %HOME%\devel\vim\vim70aa\vimtutor.bat to %VIM%\vim70aa

            3. Copy executables (and VisVim READMEs) as follows:
            a) %HOME%\devel\vim\vim70aa\src\*.exe to %VIM%\vim70aa
            b) %HOME%\devel\vim\vim70aa\src\xxd\*.exe to %VIM%\vim70aa
            c) %HOME%\devel\vim\vim70aa\src\GvimExt\*.dll to %VIM%\vim70aa
            d) %HOME%\devel\vim\vim70aa\src\VisVim\*.dll to %VIM%\vim70aa
            e) %HOME%\devel\vim\vim70aa\src\VisVim\README* to %VIM%\vim70aa

            Step 3c now fails, but see below.

            II. Move everything from "production" to "publishing"

            1. Copy recursively from %VIM%\vim70aa and below to %VIM%\pub\vim70aa
            and below.

            2. Copy %HOME%\devel\vim\vim70aa\src\GvimExt\gvimext.dll to
            %VIM%\pub\vim70aa

            III. Zip up

            Change the archive name to reflect its snapshot number, and "Update (and
            add)" it from %VIM%\pub and below, using "Maximum (portable)"
            compression. (Datestamps of runtime files are carried over all the way
            from the snapshot archive to the "publishing" directory tree, so this is
            OK.)

            All copies are "force-overwrite". Step II.2 makes sure that the
            "published" version is the latest one even if step III.3.c failed.


            Best regards,
            Tony.
          Your message has been successfully submitted and would be delivered to recipients shortly.