Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!clyde!ima!haddock!suitti
From: suitti@haddock.ima.isc.com (Stephen Uitti)
Newsgroups: comp.lang.c
Subject: Re: PD ftruncate needed
Keywords: ftruncate
Message-ID: <13754@haddock.ima.isc.com>
Date: 19 Jun 89 19:59:28 GMT
References: <2132@calypso.oakhill.UUCP> <1989Jun17.133122.7777@twwells.com>
Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti)
Distribution: usa
Organization: Interactive Systems, Boston
Lines: 75

In article <1989Jun17.133122.7777@twwells.com> bill@twwells.com (T. William Wells) writes:
>In article <2132@calypso.oakhill.UUCP> edj@oakhill.UUCP (Eric Jones) writes:
>: I am currently porting a C program from a BSD to a System V based
>: operating system. The program calls the BSD function "ftruncate",
>: which does not exist under System V.
>
>You lose. There is no way to do this in SysV 3.0 and earlier. Xenix,
>I think, has a way, and I've heard that later versions of SysV have a
>way. However, if you want portability, don't try to truncate a file
>to other than length zero.

I don't know of either a Xenix or "later version of SysV" way of
doing this in a single fast call (or small number of fast calls).

Approach 1:
	Copy the portion of the file you want to a temp file
	Delete the old
	Rename the temp file to the old name.

This is pretty portable, but
	1. doesn't fix up file descriptors that point the old file
	2. may run out of disk before finishing.
	3. May fill in "holes in files"
	4. Is slow.
	5. Has poor characteristics when interrupted.

Approach 2:
	Copy the portion of the file you want to a temp file
	Truncate the original to zero length (open using O_TRUNC?)
	Copy the portion back to the original, checking each
		block for "all zeros", and seeking past...
	delete the temp.

This is pretty portable, but
	1. may run out of disk before finishing.
	2. Is very slow.
	3. Has poor characteristics when interrupted.

Approach 3:
	Rewrite the original program(s) to not require shortening of file(s).

This is pretty portable, but
	1. may waste long term disk space or require file copies
	   or require multiple small files or,...
	2. may require significant programmer time.
	3. may have to be repeated later for other applications.

Approach 4:
	Only use applications that depend on such things on BSD
	derived systems.  This is often the cheapest, best solution.
	Of course, it may not be an option.

The BSD function "ftruncate" does not appear in POSIX P1003.1.
There does not appear to be a way to truncate a file to an
arbitrary size in POSIX.  While using BSD, i never wrote anything
that actually used it.  However, it is one of those things, that
if only one program uses it, "it is the only tool for the job",
and is thus "a good thing".

I probably would add it to an implemenation as a command to
fcntl(), using similar syntax to the locking primitives, with
similar power (being able to delete an arbitrary region, with or
without modifiing the "seek" positions of parts of the stream,
and allowing an implimentation to require "block aligned" deletes
if the end of the file is not one of the boundaries).  Likely, no
one would use this version either, but it wouldn't require
another manual page...

Stephen.

Disclaimer: If i were designing a new UNIX, i'd keep *SOME*
features the same.  For example, (largely) untyped files, and
static I/O redirection were good ideas.  Now if only efficient
database support were provided, and dynamic I/O redirection were
available (more than just redirection to /dev/null)...