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

33784Re: Config Vim not to change directory timestamp

Expand Messages
  • Gary Johnson
    Oct 3, 2003
    • 0 Attachment
      On 2003-10-03, Roboco Sanchez <roboco2004@...> wrote:
      > --- Gary Johnson <garyjohn@...> wrote:
      > > On 2003-10-03, Bram Moolenaar <Bram@...>
      > > wrote:
      > > > Roboco Sanchez wrote:
      > > >
      > > > > Vim shouldn't change the timestamp of the
      > > directory in
      > > > > which the file it's saving resides. Vim is the
      > > only
      > > > > editor to do so. It's really annoyance when you
      > > modify
      > > > > a file but your directory timestamp is also
      > > changed.
      > > > > No, I'm not talking about swap file or backup
      > > file.
      > > > > I'm talking about the directory NNNN that Vim
      > > creates
      > > > > before saving the file and deletes just after
      > > the file
      > > > > is saved. So "set backupdir" or "set directory"
      > > > > wouldn't help. Please introduce "set secretdir"
      > > for
      > > > > that NNN directory or just create it in the path
      > > of
      > > > > "set backupdir" or "set directory". Many thanks.
      > > >
      > > > I have no idea what you are talking about. Vim
      > > doesn't create a
      > > > directory next to the file it writes.
      > > >
      > > > Anyway, if you write a file it's not strange that
      > > the directory it
      > > > contains is changed. You can avoid this by
      > > letting Vim overwrite the
      > > > original file (reset 'backup' and 'writebackup')
      > > but you risk loosing
      > > > your work if the power drops that moment. On Unix
      > > the directory is
      > > > still changed anyway, since the timestamp of the
      > > file is updated.
      > >
      > > The file's timestamp is kept in the inode, not in
      > > the directory, so
      > > changing a file's contents should not affect the
      > > directory.
      > >
      > > If I have
      > >
      > > set nobackup
      > > set nowritebackup
      > > set noswapfile
      > >
      > > in my ~/.vimrc, and I use vim to modify a file, the
      > > directory time
      > > stamp is not changed. (This is using vim-6.2 on
      > > HP-UX 10.20.)
      > >
      > > I have no idea what this "NNN directory" could be,
      > > either. Some
      > > plugin?

      > You solution does solve the problem of directory
      > timestamp but you won't have the backup file in your
      > backup dir. I would still want both swapfile and
      > backupfile as normal.

      I didn't intend that to be a solution--I was only trying to verify
      my assertion that modifying a file on a Unix file system does not
      change the directory time stamp.

      > Vim does create a dir named NNNN where N is a decimal
      > digit even though you use "set backupdir" to tell Vim
      > to write backup file somewhere else. If you use
      > Windows you can use Sysinternals' FileMon to monitor
      > Vim's disk activities and you'll see the real name of
      > the dir I'm talking about. On *NIX I'm not sure what
      > tool to use.

      I know there is such a tool for Unix, but I've never used it and I
      can't think of the name.

      If I make those same settings in the C:\Vim\_vimrc file on my
      Windows2000 machine, I can also edit a file using gvim without
      changing the time stamp on the directory. So I don't doubt that
      you're seeing what you say you're seeing, but I don't think it is
      caused by vim itself. My guess is still that you have some plugin
      that defines an autocommand that's executed when you save a file.
      Try executing the following commands:

      :au BufWrite
      :au BufWritePost
      :au BufWriteCmd

      They will show you the current autocommands for each of those
      events.

      HTH,
      Gary

      --
      Gary Johnson | Agilent Technologies
      garyjohn@... | Wireless Division
      | Spokane, Washington, USA
    • Show all 18 messages in this topic