Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!steinmetz!nyfca1!brspyr1!tim
From: tim@brspyr1.BRS.Com (Tim Northrup)
Newsgroups: comp.unix.wizards
Subject: Re: a creat() hack
Message-ID: <1765@brspyr1.BRS.Com>
Date: Tue, 8-Sep-87 08:36:34 EDT
Article-I.D.: brspyr1.1765
Posted: Tue Sep  8 08:36:34 1987
Date-Received: Wed, 9-Sep-87 07:15:33 EDT
References: <3921@cit-vax.Caltech.Edu>
Organization: BRS Information Technologies, Latham NY
Lines: 34

in article <3921@cit-vax.Caltech.Edu>, mangler@cit-vax.Caltech.Edu says:
> 
> Consider an alternate implementation, which instead of truncating
> the file upon creat(), just sets a "deferred truncate" flag.  Upon
> a close() or lseek(), the file is truncated at the file pointer
> position if the flag is still set, and then the flag is reset.


What happens if the system crashes half way through a copy?  I would think
you would lose track of where the "real" EOF is for the "new" file.   This
may not be bad for most things, but for others it could be a real pain,
specifically in cases where an operation takes an extreme amount of time and
is restartable -- we would not be able to restart if we did not know where the
real EOF is.

> If a long-running program does a creat() and the machine crashes
> before anything is written, the original contents of the file are
> left untouched, gaining some of the utility of multiple versions.

This is true, but the problem comes if the long-running program DOES
write something -- the file is then in a corrupt state with no way of
telling where the "new" stuff ends and the "old" stuff continues.

> If you copy a file over itself, it doesn't clobber the file.

If you open the file for "read" first, then "creat()", the file won't
get clobbered until you close the read end.  I believe that even if the
system crashes in the middle of this, the file will not be clobbered.

> Don Speck   speck@vlsi.caltech.edu  {amdahl,rutgers}!cit-vax!speck
-- 
============================================    Tim "The Enchanter" Northrup
tim@brspyr1.BRS.Com
uunet!steinmetz!brspyr1!tim