chris@mimsy.UUCP (Chris Torek) (08/15/89)
-In article <19072@mimsy.UUCP> I remarked that ->The 4BSD ftruncate() call will not extend files. (If it did, ->it would probably have been called `fsetsize'; .... In article <c0rl029p4a1201@amdahl.uts.amdahl.com> kucharsk@uts.amdahl.com (William Kucharski) writes: -Well, it may not be a good porting guide, but my SunOS 4.0 man page says: - -DESCRIPTION - truncate() causes the file referred to by path (or for - ftruncate() the object referred to by fd) to have a size - equal to length bytes. ... [If this extends the file,] bytes - between the old and new lengths are read as zeroes. [...] This is either a bug in the SunOS manpage (there are, it seems, many such) or---in this particular case, more likely---Yet Another Difference between SunOS and 4BSD. Here the function is useful, but the name is bad. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
guy@auspex.auspex.com (Guy Harris) (08/17/89)
>This is either a bug in the SunOS manpage (there are, it seems, many >such) or---in this particular case, more likely---Yet Another Difference >between SunOS and 4BSD. Here the function is useful, but the name is >bad. It is Yet Another Difference between SunOS 4.x and 4BSD. The name is unfortunate, but I guess they didn't feel like adding a new call. S5R4 will do all the file size adjusting functions with F_FREESP, and said call is ultimately intended to let you punch holes in files as well (the name is still arguably unfortunate, for although the "truncate" and "punch a hole" functions do free up disk blocks, the "extend" function, while I think it may not consume disk blocks on file systems that support "holes", does grow the file). I've never been wild about using "fcntl" for stuff like that anyway; you can write wrappers to perform the different F_FREESP functions, if you want, and give them better names....