[Bug 1059085] Re: Lucid: recovery silently deletes data in large files.

[Launchpad Bug Tracker]

This bug was fixed in the package vim - 2:7.2.330-1ubuntu3.1

---------------
vim (2:7.2.330-1ubuntu3.1) lucid-proposed; urgency=low

  * Backported upstream patch 7.3.216 from
    https://groups.google.com/d/topic/vim_dev/lTos-bGcNgU/discussion
    (LP: #1059085):
    - src/memline.c: Avoid corruption on large-file recovery.
    - src/testdir/test70.in, src/testdir/test70.ok:
      Test large-file recovery.
    - src/testdir/Makefile, src/testdir/Make_amiga.mak,
      src/testdir/Make_dos.mak, src/testdir/Make_os2.mak,
      src/testdir/Make_vms.mms: Update Makefiles to include new tests.
 -- Adam Buchbinder <adam.buchbinder at gmail.com>   Sun, 30 Sep 2012 10:44:38 -0400

** Changed in: vim (Ubuntu Lucid)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1059085

Title:
  Lucid: recovery silently deletes data in large files.

Status in “vim” package in Ubuntu:
  Fix Released
Status in “vim” source package in Lucid:
  Fix Released
Status in “vim” source package in Precise:
  Fix Released
Status in “vim” source package in Quantal:
  Fix Released
Status in “vim” source package in Raring:
  Fix Released

Bug description:
  This is present in vim 2:7.2.330-1ubuntu3, in Lucid. It was fixed
  upstream in 7.3.216, which is in Precise and newer. To replicate the
  bug (taken from
  https://groups.google.com/d/topic/vim_use/CNuBWi0763I/discussion):

  [Summary]

  The recovery process silently deletes part of the file it's run on,
  when the file is large enough (40,000 lines seems to trigger it).

  [Impact]

  The recovery process, while it may not recover all of the user's
  changes since the process was killed, is expected to at least not
  destroy random chunks of data in the middle of a large file. This bug
  has bitten me at least twice--silently!--before I found out what was
  going on.

  [Test Case]

  1. Run 'vi test.txt'.
  2. Type '78a-' [ESC], then 'yy', '39999p', then ':wq', to create a 40,000-line test file.
  3. Run 'cp test.txt test.bak'.
  4. Run 'vi test.txt'.
  5. Type 'Ox' to make a small change to the file.
  6. From another terminal window, run 'ps x|grep [t]est.txt' to find the PID of the running vim process.
  7. Run 'kill $PID' to terminate the process.
  8. Run 'vi test.txt', and type 'r' to attempt recovery, then ':wq' to save the recovered contents.
  9. Run 'wc -l test.txt test.bak'.

  Expected output:
  $ wc -l test.txt test.bak
    40001 test.txt
    40000 test.bak

  Actual output:
  $ wc -l test.txt test.bak
    38629 test.txt
    40000 test.bak

  [Regression Potential]

  Small. The patch I'm backporting
  (https://groups.google.com/d/topic/vim_dev/lTos-bGcNgU/discussion) in
  is part of the new 7.3 series, and vim has a large test suite; I'm
  porting and checking the patch as-is, including its tests. If this
  breaks the recovery process, the regression tests will catch it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1059085/+subscriptions