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
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


--
Jeff Squyres
Cisco Systems

Reply via email to