gaspar@ALMSA-1.arpa (Al Gaspar) (10/18/87)
We have several flavors of UN*X running at our installation: Sperry 5000/80's running Sys V, a Plexus P60 running Sys V, a Vax 750 and a Vax 780 both running 4.2 BSD, and some Intel 310's running Xenix 3.0. We have noticed a glitch in vi on the non-BSD implementations. If you go into a large file (1000 lines or so) with vi and send some of it out to a filter with !, you will corrupt the file. We started on line 1 and did a !G and then a tee to a new filename. After three or four tries with different file names, an ls -l on the resulting files showed differing sizes and a diff with the original showed garbled data in the original file. This seems to be a bug with the vi code for pageing systems. Has anyone else experienced this? Any comments? Fixes? Cheers-- Al -- Al Gaspar <gaspar@almsa-1.arpa> USAMC ALMSA, ATTN: AMXAL-OW, Box 1578, St. Louis, MO 63188-1578 COMMERCIAL: (314) 263-5118 AUTOVON: 693-5118 seismo!gaspar@almsa-1.arpa
boykin@custom.UUCP (Joseph Boykin) (10/20/87)
In article <4897@ncoast.UUCP>, gaspar@ALMSA-1.arpa (Al Gaspar) writes: > We have several flavors of UN*X running at our installation: Sperry 5000/80's > running Sys V, a Plexus P60 running Sys V, a Vax 750 and a Vax 780 both > running 4.2 BSD, and some Intel 310's running Xenix 3.0. We have noticed a > glitch in vi on the non-BSD implementations. If you go into a large file (1000 > lines or so) with vi and send some of it out to a filter with !, you will > corrupt the file. We started on line 1 and did a !G and then a tee to a new > filename. After three or four tries with different file names, an ls -l on > the resulting files showed differing sizes and a diff with the original showed > garbled data in the original file. This seems to be a bug with the vi code > for pageing systems. Has anyone else experienced this? Any comments? Fixes? Without a few more details it's hard to definitively say what is going on, but I think I can make a good stab at it. When doing a filter UNIX VI forks; one process writes to the program, while the other reads the results. The problem is that they are both using the same temporary file to figure out where the data is coming from (in the original file) and where to place it (the output of the filter). On BSD systems there is some additional buffering such that more information is kept incore. The result is that BSD VI will corrupt the file *less often*. Note that *any* UNIX VI can potentially corrupt the file if the number of lines is large enough. The size is dependent on the version of VI you are using. Potentially, more than 1 line is dangerous. As for why different things happened on different iterations; simple, other programs affected scheduling of the two VI processes and affected the contents of the buffer cache. The bottom line here is that this is a known problem in UNIX VI and large filters should be avoided. Small ones are OK. Note that this problem does not occur for PC/VI. Even if we wanted to use the same scheme, having two independent processes under DOS isn't doable! -- Joe Boykin Custom Software Systems ...necntc!custom!boykin