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

Gvim changes uid:gid when writing a file accessed via Samba

Expand Messages
  • Keith Roberts
    Ok, gurus! I need some help on this one. As the subject says, using gvim -u NONE -U NONE w: KROBERTS filename where w: is a mapped drive pointing to a unix
    Message 1 of 8 , Aug 30, 2004
    • 0 Attachment
      Ok, gurus! I need some help on this one.

      As the subject says, using

      gvim -u NONE -U NONE w:\KROBERTS\filename

      where w: is a mapped drive pointing to a unix filesystem and filename
      already exists, alters the uid and the gid of the edited file to those
      of the login used to map the drive. It shouldn't do this. I can edit
      the file with Wordpad w/o changing attributes, so it's not Samba doing
      it (as I had previously thought). And vanilla gvim does it, so it's not
      my customizations, either. Any suggestions?

      Here's the unix:
      [kroberts@uv2 KROBERTS]$ uname -a
      Linux uv2.wpas-inc.com 2.2.19-7.0.8.DPTenterprise #1 SMP Wed Jul 11
      16:19:36 EDT 2001 i686 unknown

      And here's the gvim:
      VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Feb 24 2004 08:09:16)
      MS-Windows 32 bit GUI version with OLE support
      Included patches: 1-287
      Compiled by ronaaron@REDMOND
      Big version with GUI. Features included (+) or not (-):
      +arabic +autocmd -balloon_eval +browse ++builtin_terms +byte_offset
      +cindent
      +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
      +comments
      +cryptv +cscope +dialog_con_gui +diff +digraphs -dnd -ebcdic +emacs_tags
      +eval
      +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding
      -footer
      +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap
      +langmap
      +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
      +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang
      -netbeans_intg
      +ole -osfiletype +path_extra -perl -postscript +printer -python
      +quickfix
      +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline
      -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl
      -tgetent
      -termresponse +textobjects +title +toolbar +user_commands +vertsplit
      +virtualedit +visual +visualextra +viminfo +vreplace +wildignore
      +wildmenu
      +windows +writebackup -xfontset -xim -xterm_save -xpm_w32
      system vimrc file: "$VIM\vimrc"
      user vimrc file: "$HOME\_vimrc"
      2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
      2nd user exrc file: "$VIM\_exrc"
      system gvimrc file: "$VIM\gvimrc"
      user gvimrc file: "$HOME\_gvimrc"
      2nd user gvimrc file: "$VIM\_gvimrc"
      system menu file: "$VIMRUNTIME\menu.vim"
      Compilation: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400
      -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H
      -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_GUI_W32
      -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
      -DDYNAMIC_ICONV -pipe -w -march=i386 -mcpu=i686 -Wall -O6
      -fomit-frame-pointer -freg-struct-return -malign-double -s
      Linking: gcc -s -o gvim.exe -lkernel32 -luser32 -lgdi32 -ladvapi32
      -lcomdlg32 -lcomctl32 -loleaut32 -lstdc++ -luuid -lole32

      --
      Keith W. Roberts Home: keith.roberts5@...
      WPAS, Inc. Work: kroberts@...
      P.O. Box 34203 Phone: (206) 441-7574 x. 3810
      Seattle, WA 98124 Fax: (206)682-5826 / 441-9110
      (remove x's from email addresses)
    • Tim Chase
      ... You might check the ... (it s also available in the os_win32.txt, but not so nicely tagged with a help-tag target, among a list of FAQs) If you re getting
      Message 2 of 8 , Aug 30, 2004
      • 0 Attachment
        > where w: is a mapped drive pointing to a unix filesystem and filename
        > already exists, alters the uid and the gid of the edited file to those
        > of the login used to map the drive. It shouldn't do this. I can edit
        > the file with Wordpad w/o changing attributes, so it's not Samba doing
        > it (as I had previously thought). And vanilla gvim does it, so it's not
        > my customizations, either. Any suggestions?

        You might check the

        :he msdos-linked-files

        (it's also available in the os_win32.txt, but not so nicely
        tagged with a help-tag target, among a list of FAQs)

        If you're getting backup files when you write, it looks like it
        would be your 'writebackup' setting that's causing the behavior.

        Hope this helps,

        -tim
      • Keith Roberts
        ... This is a good link, but let s take a look at it ... ============================================================= =8. Symbolically linked files
        Message 3 of 8 , Aug 30, 2004
        • 0 Attachment
          >-----Original Message-----
          >From: Tim Chase [mailto:vim@...]
          >Sent: Monday, August 30, 2004 12:38 PM
          >To: Keith Roberts
          >Cc: vim-ML
          >Subject: Re: Gvim changes uid:gid when writing a file accessed
          >via Samba
          >
          >> where w: is a mapped drive pointing to a unix filesystem and
          >filename
          >> already exists, alters the uid and the gid of the edited
          >file to those
          >> of the login used to map the drive. It shouldn't do this.
          >I can edit
          >> the file with Wordpad w/o changing attributes, so it's not
          >Samba doing
          >> it (as I had previously thought). And vanilla gvim does it, so it's
          >> not my customizations, either. Any suggestions?
          >
          >You might check the
          >
          > :he msdos-linked-files
          >
          >(it's also available in the os_win32.txt, but not so nicely
          >tagged with a help-tag target, among a list of FAQs)
          >
          >If you're getting backup files when you write, it looks like
          >it would be your 'writebackup' setting that's causing the behavior.
          >
          >Hope this helps,
          >
          >-tim

          This is a good link, but let's take a look at it ...

          =============================================================
          =8. Symbolically linked files *msdos-linked-files*
          =
          =When using Vim to edit a symbolically linked file on a unix
          =NFS file server, you may run into problems.

          Does a Windows "mapped drive" constitute a symlink? IIUC,
          Samba makes a unix file look to Windows like just another
          Windows file, which presumably means that Vim wouldn't even
          know it wasn't writing a "local" file. [Perhaps I am
          hopelessly naïve? But this seems completely different from
          pc-NFS, which runs on the Windows box and accesses NFS files
          directly.]

          =When writing the file, Vim does not "write through" the
          =symlink. Instead, it deletes the symbolic link and creates
          =a new file in its place.

          This would be in line with what I am seeing.

          =On Unix, Vim is prepared for links (symbolic or hard). A
          =backup copy of the original file is made and then the
          =original file is overwritten. This assures that all
          =properties of the file remain the same. On non-Unix
          =systems, the original file is renamed and a new file is
          =written. Only the protection bits are set like the original
          =file. However, this doesn't work properly when working on
          =an NFS-mounted file system where links and other things
          =exist. The only way to fix this in the current version is
          =not making a backup file, by ":set nobackup nowritebackup"
          =|'writebackup'|
          =============================================================

          The above advice is not necessarily the solution. I need 'wb', because I am using 'patchmode'. The solution is to :set bkc=yes, which makes the backup file the copy, leaving the attributes (uid, gid, modes) of the file itself unchanged.
        • Antoine J. Mechelynck
          ... [...] I think it s a lack of customization: see :help backupcopy . Your W32 gvim doesn t know that you re calling it from Unix, so it s making a new
          Message 4 of 8 , Aug 30, 2004
          • 0 Attachment
            Keith Roberts <kroberts@...> wrote:
            > Ok, gurus! I need some help on this one.
            >
            > As the subject says, using
            >
            > gvim -u NONE -U NONE w:\KROBERTS\filename
            >
            > where w: is a mapped drive pointing to a unix filesystem and filename
            > already exists, alters the uid and the gid of the edited file to those
            > of the login used to map the drive. It shouldn't do this. I can edit
            > the file with Wordpad w/o changing attributes, so it's not Samba doing
            > it (as I had previously thought). And vanilla gvim does it, so it's
            > not my customizations, either. Any suggestions?
            [...]

            I think it's a lack of customization: see ":help 'backupcopy'". Your W32
            gvim doesn't know that you're calling it from Unix, so it's making a new
            copy of the file and renaming the old one as the backup, which it probably
            deletes after a successful write. Try ":set backupcopy=yes" to overwrite the
            original file (preserving chown and chmod settings) and create a new file if
            and when a backup is needed.

            Regards,
            Tony.
          • Keith Roberts
            ... Yes, thanks Tony. I figured that out in the process of answering Tim Chase s reply. :) Works fine now.
            Message 5 of 8 , Aug 31, 2004
            • 0 Attachment
              >-----Original Message-----
              >From: Antoine J. Mechelynck [mailto:antoine.mechelynck@...]
              >Sent: Monday, August 30, 2004 4:57 PM
              >To: Keith Roberts; vim-ML
              >Subject: Re: Gvim changes uid:gid when writing a file accessed
              >via Samba
              >
              >Keith Roberts <kroberts@...> wrote:
              >> Ok, gurus! I need some help on this one.
              >>
              >> As the subject says, using
              >>
              >> gvim -u NONE -U NONE w:\KROBERTS\filename
              >>
              >> where w: is a mapped drive pointing to a unix filesystem and
              >filename
              >> already exists, alters the uid and the gid of the edited
              >file to those
              >> of the login used to map the drive. It shouldn't do this.
              >I can edit
              >> the file with Wordpad w/o changing attributes, so it's not
              >Samba doing
              >> it (as I had previously thought). And vanilla gvim does it, so it's
              >> not my customizations, either. Any suggestions?
              >[...]
              >
              >I think it's a lack of customization: see ":help
              >'backupcopy'". Your W32 gvim doesn't know that you're calling
              >it from Unix, so it's making a new copy of the file and
              >renaming the old one as the backup, which it probably deletes
              >after a successful write. Try ":set backupcopy=yes" to
              >overwrite the original file (preserving chown and chmod
              >settings) and create a new file if and when a backup is needed.
              >
              >Regards,
              >Tony.

              Yes, thanks Tony. I figured that out in the process of answering Tim
              Chase's reply. :) Works fine now.
            • Keith Roberts
              ... Update (for anyone else out there with the same problem): 1) if you :set bkc=yes and :w it does work the way it should, BUT 2) if you use sessions,
              Message 6 of 8 , Aug 31, 2004
              • 0 Attachment
                > -----Original Message-----
                > From: Keith Roberts [mailto:kroberts@...]
                > Sent: Tuesday, August 31, 2004 7:26 AM
                > To: Antoine J. Mechelynck; vim-ML
                > Subject: RE: Gvim changes uid:gid when writing a file accessed via
                > Samba
                >
                Antoine J. Mechelynck wrote:
                >> Keith Roberts <kroberts@...> wrote:
                >>> Ok, gurus! I need some help on this one.
                >>>
                >>> As the subject says, using
                >>>
                >>> gvim -u NONE -U NONE w:\KROBERTS\filename
                >>>
                >>> where w: is a mapped drive pointing to a unix filesystem and
                >>> filename already exists, alters the uid and the gid of the edited
                >>> file to those of the login used to map the drive. It shouldn't do
                >>> this. I can edit the file with Wordpad w/o changing attributes, so
                >>> it's not Samba doing it (as I had previously thought). And vanilla
                >>> gvim does it, so it's not my customizations, either. Any
                >>> suggestions? [...]
                >>
                >> I think it's a lack of customization: see ":help 'backupcopy'". Your
                >> W32 gvim doesn't know that you're calling it from Unix, so it's
                >> making a new copy of the file and renaming the old one as the
                >> backup, which it probably deletes after a successful write. Try
                >> ":set backupcopy=yes" to overwrite the original file (preserving
                >> chown and chmod
                >> settings) and create a new file if and when a backup is needed.
                >>
                >> Regards,
                >> Tony.
                >
                > Yes, thanks Tony. I figured that out in the process of
                > answering Tim Chase's reply. :) Works fine now.


                Update (for anyone else out there with the same problem):

                1) if you :set bkc=yes and :w it does work the way it should, BUT

                2) if you use sessions, :mksession does a :set nocp right up top, which
                *undoes* the 'bkc' setting!! Now there's been an item in the To Do list
                for this for a long time -- months, perhaps more than a year -- turned
                in by my brother (Ron Aaron). I imagine he reported this because of me,
                but at that time I didn't have time (or knowhow) to find a solution for
                it.

                3) since the session stuff is done *after* all vimrc and project
                settings, the only way I can think of to override this ugly behavior is
                to create a VimEnter autocommand to set it.
              • Bram Moolenaar
                ... :mksession generates a script that only resets compatible when it s not off yet. All option values are restored anyway. Are you using an old Vim
                Message 7 of 8 , Sep 1, 2004
                • 0 Attachment
                  Keith Roberts wrote:

                  > Update (for anyone else out there with the same problem):
                  >
                  > 1) if you :set bkc=yes and :w it does work the way it should, BUT
                  >
                  > 2) if you use sessions, :mksession does a :set nocp right up top, which
                  > *undoes* the 'bkc' setting!! Now there's been an item in the To Do list
                  > for this for a long time -- months, perhaps more than a year -- turned
                  > in by my brother (Ron Aaron). I imagine he reported this because of me,
                  > but at that time I didn't have time (or knowhow) to find a solution for
                  > it.

                  ":mksession" generates a script that only resets 'compatible' when it's
                  not off yet. All option values are restored anyway. Are you using an
                  old Vim version? This was changed in patch 6.2.437.

                  --
                  A cow comes flying over the battlements, lowing aggressively. The cow
                  lands on GALAHAD'S PAGE, squashing him completely.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                  \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                • Keith Roberts
                  ... Ah, very good. I m still on 6.2.287 -- haven t upgraded to Ron s latest yet because he changed some things on me that require some significant changes of
                  Message 8 of 8 , Sep 1, 2004
                  • 0 Attachment
                    >-----Original Message-----
                    >From: Bram@... [mailto:Bram@...]
                    >Sent: Wednesday, September 01, 2004 2:03 AM
                    >To: Keith Roberts
                    >Cc: Antoine J. Mechelynck; vim-ML
                    >Subject: RE: Gvim changes uid:gid when writing a file accessed
                    >via Samba
                    >
                    >
                    >Keith Roberts wrote:
                    >
                    >> Update (for anyone else out there with the same problem):
                    >>
                    >> 1) if you :set bkc=yes and :w it does work the way it should, BUT
                    >>
                    >> 2) if you use sessions, :mksession does a :set nocp right up top,
                    >> which
                    >> *undoes* the 'bkc' setting!! Now there's been an item in the To Do
                    >> list for this for a long time -- months, perhaps more than a year --
                    >> turned in by my brother (Ron Aaron). I imagine he reported this
                    >> because of me, but at that time I didn't have time (or knowhow) to
                    >> find a solution for it.
                    >
                    >":mksession" generates a script that only resets 'compatible'
                    >when it's not off yet. All option values are restored anyway.
                    > Are you using an old Vim version? This was changed in patch >6.2.437.

                    Ah, very good. I'm still on 6.2.287 -- haven't upgraded to Ron's latest
                    yet because he changed some things on me that require some significant
                    changes of my own. :)

                    But that means that http://vim.sourceforge.net/htmldoc/todo.html is
                    incorrect, as it still shows up there.

                    What's the easiest way to find out if something's been fixed in a newer
                    release than I have?
                  Your message has been successfully submitted and would be delivered to recipients shortly.