F_FREESP argument to fcntl() (was: Re: sparse files)

[Guy Harris]

 >>Not in general, anyway.  At least the first version of AIX for the RT PC
 >>claimed, in its documentation, that it had an "fclear()" call to punch
 >>holes in files; I think this may show up in future releases of other
 >>UNIXes as well.
 >
 >I think the *undocumented* F_FREESP argument to fcntl()
 >in lots of versions of SYSVR3 can do this too.
 >Take a look in /usr/include/sys/fcntl.h to find out if yours has it.

And then take a look in "/usr/src/uts/3b2/fs/s5/s5sys3.c" to see if it
has the following comment in front of "s5freesp":

/*
 * Free storage space associated with the specified inode.  The portion
 * to be freed is specified by lp->l_start and lp->l_len (already
 * normalized to a "whence" of 0).
 * This is an experimental facility for SVR3.1 and WILL be changed
 * in the next release.  Currently, we only support the special case
 * of l_len == 0, meaning free to end of file.
 *
 * Blocks are freed in reverse order.  This FILO algorithm will tend to
 * maintain a contiguous free list much longer than FIFO.
 * See also s5itrunc() in s5iget.c.
 *
 * Bug:  unused bytes in the last retained block are not cleared.
 * This may result in a "hole" in the file that does not read as zeroes.
 */

which sure makes it look as if you can *NOT* use F_FREESP to punch holes
in files, at least not in S5R3.1.  The intent is to ultimately have
F_FREESP allow you to punch holes in files; I have no idea which file
systems, if any, allow you to do that in S5R4.  (Actually, I know that
the NFS file system type doesn't, since there's no "punch a hole in a
file" NFS operation in the version 2 protocol; some servers may detect
attempts to write entire blocks full of zeroes and turn that into a
"punch a hole" operation, but that's not guaranteed by the protocol.)

>Some time ago somebody posted a SYSV implementation of
>ftruncate(). It used F_FREESP to chop off the end of a file.
>But I see no reason why it could not be used to punch 
>a hole in the middle of a file.

I see such a reason, namely that the code that implements F_FREESP
doesn't support anything other than truncation (yes, the S5R3.1 version
checks for "l_len == 0", and returns EINVAL if it isn't equal to 0; I
think the S5R3.2 version is similar).