Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.unix.wizards Subject: ftruncate broken? - Sun-based NFS Message-ID: <1579@mcgill-vision.UUCP> Date: 9 Jul 89 05:13:16 GMT Organization: McGill University, Montreal Lines: 62 The ftruncate() call appears to be broken on at least some systems with NFS implementations based on Sun's. I've tried this on a Sun-3 with release 3.5 and on a VAX running mtXinu 4.3+NFS. I also tried it on a MicroVAX running real 4.3, and it did not exhibit the broken behavior. But it's not directly an NFS problem, because it happens even when the file is on a ufs filesystem. The problem is that ftruncate() fails if the file modes prohibit writing, even if the file descriptor used does permit writing. For example, try the following program on a handy Sun. Notice that (unless you try it as super-user), the ftruncate call fails. Try it on a 4.3 machine, though, and everything's fine. (I checked the Sun manpage, and there's not even a note in the BUGS section warning about this, so presumably someone thinks it should work the way it does on 4.3.) Anybody have a simple fix? (Patch a couple of bytes to noops somewhere in the OBJ/ files perhaps?) Will it be fixed in newer releases (4.x)? I'm about ready to try to work out a fix on the mtXinu system, to which we have source, but that's not much help on the Suns. #include int fd; char junk[8192]; main() { unlink("test.file"); fd = open("test.file",O_RDWR|O_CREAT|O_TRUNC,0666); if (fd < 0) { perror("open/create test.file"); exit(1); } if (write(fd,&junk[0],8192) != 8192) { perror("write #1"); exit(1); } if (fchmod(fd,0444) < 0) { perror("fchmod"); exit(1); } if (write(fd,&junk[0],8192) != 8192) { perror("write #2"); exit(1); } if (ftruncate(fd,(unsigned long int)16000) < 0) { perror("ftruncate"); exit(1); } if (close(fd) < 0) { perror("close"); exit(1); } exit(0); } der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu