Xref: utzoo comp.os.msdos.programmer:307 comp.lang.c:30656 comp.sources.wanted:12671
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!uwvax!galtee.cs.wisc.edu!rose
From: rose@galtee.cs.wisc.edu (Barney Frank)
Newsgroups: comp.os.msdos.programmer,comp.lang.c,comp.sources.wanted
Subject: Truncate a File?
Message-ID: <10914@spool.cs.wisc.edu>
Date: 30 Jul 90 15:12:01 GMT
Sender: root@spool.cs.wisc.edu
Distribution: comp
Organization: U of Wisconsin CS Dept
Lines: 32

I have a requirement to adjust the length of a data file.

1. Open the file for read and write.
2. Archive the earliest information in the file to another file system.
3. Move the latest information to the head of the file.
4. Ask the operating system to adjust the size of the file down to the new
	"high-water" mark.

  It is not sufficient to make a temporary copy of the section of
interest, unlink the original file, and rename the temporary, because
the size of the file is of the same order of that of the file system.
Specifically, what I need to do is

This sounds like a pretty elementary operation to me, but I'll be
damned if I can find a system call to do anything to the size of a
file other than just move it down to zero.  One can envision some
pretty complicated schemes involving reading and writing the FAT
directly, but such schemes lack portability and have the potential to
run afoul of various caching schemes.  Yet I know that it can be done,
because I am aware of at least one program that is able to pack a data
file in-place in this fashion.

Right now, I am thinking of falling back to a fixed file length
scheme- that is, to allocate a file as large as I can afford, never
adjust the size, and use an alternative data structure to keep track
of the high-water point.  I'd be very happy to hear any suggestions
that allow me to avoid this, though.  Thanks in advance.

	-Scott Rose
--
	Scott Rose
	rose@cs.wisc.edu