gaspar@ALMSA-1.arpa (Al Gaspar) (06/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) (06/19/87)
In article <7903@brl-adm.ARPA>, 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. While at the USENIX conference I was discussing the addition of filters to PC/VI with someone who visited the booth. While I haven't totally confirmed this persons opinion, it went something like this: "Filtering a portion of the buffer is actually the combination of writing the buffer to a pipe and reading the results back in. To do this, UNIX VI forks itself and has one process do the write, and the other do the read." I've tried doing such a filter using VI Version 3.7 on a SV kernel on one terminal and running alot of PS's on another and this does indeed seem to be what is happening. This sounds like a nice idea. The problem is that where the data is coming from is taken from information contained in a temporary file. The data is likewise written to the buffer with the appropriate updates to the *same* temporary file. Given that these two copies of VI are asynchronous, the VI writing to the pipe is using data which has already been modified by the VI reading from the pipe. The result is that the temporary file, and hence the file which will later be written out, is corrupted. The reason this isn't seen with smaller portions of text has to do with buffering done by the kernel, process scheduling and some good luck! The bottom line is that, given the way VI implements this dual operation, the file is very likely to be corrupted. The fact that it doesn't happen when filtering small portions of the buffer is a matter of luck. Joe Boykin Custom Software Systems ...necntc!custom!boykin