How about just write()ing a bunch of 0's instead of using ftruncate?
On Mar 27, 2009, at 11:09 PM, Eugene Loh wrote:
> Paul H. Hargrove wrote:
>
> > Quoting from a different manpage for ftruncate:
> > [T]he POSIX standard allows two behaviours for ftruncate
> > when length exceeds the file length [...]: either returning
> an
> > error, or
> > extending the file.
> > So, if that is to be trusted, it is not legal by POSIX to *silently*
> > not extend the file.
>
> On a Solaris system, the ftruncate man page says:
>
> truncate, ftruncate - set a file to a specified length
>
> The truncate() function causes the regular file named by
> path to have a size equal to length bytes.
>
> If the file previously was larger than length, the extra
> data is discarded. If the file was previously shorter than
> length, its size is increased, and the extended area appears
> as if it were zero-filled.
>
> So, the sense is not of "truncating" (shortening) per se, but of
> fixing
> a new length, whether that length is longer or shorter.
>
> I guess we could try to track down the ftruncate behavior on the
> systems
> in question, but (IMHO) this doesn't feel like the correct
> explanation.
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}