Xref: utzoo comp.lang.c:38663 comp.unix.questions:30691
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!chaph.usc.edu!alcor.usc.edu!jeenglis
From: jeenglis@alcor.usc.edu (Joe English)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: Truncating an existing file (and lockf question)
Message-ID: <16836@chaph.usc.edu>
Date: 24 Apr 91 18:00:32 GMT
References: <3172@dsacg3.dsac.dla.mil>
Sender: news@chaph.usc.edu
Followup-To: comp.unix.questions
Distribution: usa
Organization: Free Roger Carasso
Lines: 33
Nntp-Posting-Host: alcor.usc.edu

nto0302@dsacg3.dsac.dla.mil (Bob Fisher) writes:
>How can I truncate the end of a large file without copying the part
>to be preserved to a new file and then doing a remove/rename?
>
>This is for SVR3 but may need ported to BSD4.3.

Check for a system call called 'truncate' or 'ftruncate'.
SunOS has these, but the man pages are (as usual) unclear
as to whether they're from BSD, System V, both, or neither.
I seem to remember seeing this under both BSD4.3 and SVR3.

This brings up another question:  I was looking under the
man page for 'fcntl' to see if it had a truncate option,
and found the following under the description of F_SETLK:


     A shared or exclusive lock is either advisory  or  mandatory
     depending on the mode bits of the file containing the locked
     segment.  The lock is mandatory if the set-GID bit (S_ISGID)
     is  set  and  the  group execute bit (S_IXGRP) is clear (see
     stat(2V) for information about mode bits).   Otherwise,  the
     lock is advisory.


This sounds really weird.  Why should locking behaviour depend 
on the setgid bit?   Is this just a SunOS quirk?

Followups to comp.unix.questions....


--Joe English

  jeenglis@alcor.usc.edu