*** common/exf.c.orig Mon Aug 15 14:01:57 1994 --- common/exf.c Mon Aug 15 14:18:31 1994 *************** *** 601,606 **** --- 601,620 ---- return (1); } + #if __linux__ + /* + * In libc 4.5.x, fdopen(fd, "w") clears the O_APPEND flag (if set). + * This bug is fixed in libc 4.6.x. + * + * This code works around this problem for libc 4.5.x users. + * Note that this code is harmless if you're using libc 4.6.x. + */ + if (LF_ISSET(FS_APPEND) && lseek(fd, (off_t)0, SEEK_END) < 0) { + msgq(sp, M_SYSERR, name); + return (1); + } + #endif + /* Use stdio for buffering. */ if ((fp = fdopen(fd, "w")) == NULL) { (void)close(fd); *** PORT/db/recno/rec_open.c.orig Mon Aug 15 14:02:13 1994 --- PORT/db/recno/rec_open.c Mon Aug 15 14:16:57 1994 *************** *** 160,168 **** --- 160,187 ---- SET(t, R_EOF); else { t->bt_msize = sb.st_size; + #if !__linux__ + /* + * On Linux 1.1.35 and earlier, read only private mappings cause write only + * and read/write opens to fail with errno=ETXTBSY, so for those older + * versions of the kernel, this mmap() call should be commented out. + * This bug is fixed on 1.1.36 and later. + * + * Also, as of Linux 1.1.44, mmap() does not work together with the buffer + * cache. The specific problem is changes made to a file via write() do + * not appear in memory mapped pages of that file, which causes confusing + * things to happen if you write out the file you're editing without + * quitting vi and try to GNU grep for the change you just wrote out. + * Since GNU grep uses mmap(), it grabs the memory mapped pages that vi is + * holding open due to this mmap() call, and ends up not seeing the change + * you wrote out because the memory mapped pages are out of date. + * + * So, until mmap() is fixed, we will avoid it here and use the slow method. + */ if ((t->bt_smap = mmap(NULL, t->bt_msize, PROT_READ, MAP_PRIVATE, rfd, (off_t)0)) == (caddr_t)-1) + #endif goto slow; t->bt_cmap = t->bt_smap; t->bt_emap = t->bt_smap + sb.st_size;