| 2012-09-30 15:06:32 |
Adam Buchbinder |
description |
This is present in vim 2:7.2.330-1ubuntu3, in Lucid. It was fixed upstream in 7.3.216. 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. |
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. |
|
