[comp.unix.questions] Truncating an existing file

jeenglis@alcor.usc.edu (Joe English) (04/25/91)

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

jik@athena.mit.edu (Jonathan I. Kamens) (04/25/91)

In article <16836@chaph.usc.edu>, jeenglis@alcor.usc.edu (Joe English) writes:
|>      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?

  They're simply using the S_ISGID bit to store additional information, when
it isn't being used to indicate a setgid executable.  Notice that it only
indicates mandatory locks when the group-executable bit isn't set.  This means
that it has nothing to do with locking when the file *is* group-executable;
instead, it takes on its traditionaal task of indicating a setgid executable.

  Overloading of permission bits has become somewhat common as people find
more and more information that needs to be stored.  For example, the use of
the sticky bit to indicate sticky directories is a somewhat late addition.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710

ets@wrkgrp.COM (Edward T Spire) (04/25/91)

In article <16836@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English) writes:
>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.

ftruncate() seems to work everywhere we've tried, except
SCO/Unix.  W/ SCO/Unix, chsize() takes the same parms as
ftruncate() and does the same thing...

========================================================================

Ed Spire                           email: ets@wrkgrp.com      (on uunet)
The Workstation Group              voice: 800-228-0255
6300 River Road, Suite 700            or  708-696-4800
Rosemont, Illinois  60018            fax: 708-696-2277

urban@cbnewsl.att.com (john.urban) (04/25/91)

In article <1991Apr25.144430.350@wrkgrp.COM> ets@wrkgrp.COM (Edward T Spire) writes:
>In article <16836@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English) writes:
>SCO/Unix.  W/ SCO/Unix, chsize() takes the same parms as
>ftruncate() and does the same thing...
>
>========================================================================

chsize is also available for UNIX System V/386 Release 3.2, and UNIX System V/386
Release 4.0.  Little example ...

$ cat C.c
#include <fcntl.h>
main()
{
	int a;
	a = open("/tmp/passwd", O_WRONLY);
	chsize (a, 20L);
	close (a);
}
$ cp /etc/passwd /tmp/passwd
$ cc -O C.c -o C -lx
$ ./C
$ ls -l /tmp/passwd
-r--r--r-- 1 install other  20 Apr 25 11:17 /tmp/passwd


Sincerely,

John Urban