Rename bug?

[Rich Strebendt, AT&T-DSG @ Indian Hill West]

In article <5730 at chinet.UUCP>, les at chinet.UUCP (Leslie Mikesell) writes:
>
> Given an existing file xx which several people may be reading, and
> new data in a file TMP4653 that is supposed to replace file xx, and
> no atomic rename() function, what do you do?  It is kind of anti-social
> to copy on top of a file that someone is reading since they might see
> part of the old file and part of the new, so you are left with:
> 
> unlink("xx");  /* anyone who has it open will still see the old file */
> link("TMP4653","xx"); /* opening now will get the new file */
> unlink("TMP4653"); /* cleanup */
> 
> This leaves an interval between unlink("xx") and link("TMP4653","xx")
> when an attempt to open("xx") will fail.  I work with a system that
> has about 10,000 files on line that are mostly updated daily, some
> every 10 minutes, and it seems like a real kludge that I had to make
> the retrieval program attempt open() twice with a sleep() in between
> to be sure of finding the file.  Can it be done otherwise?

This kind of problem was handled routinely on IBM TSS/360/370 with
Generation Data Groups.  Perhaps something similar should be developed
for UNIX.  All a GDG was was a collection of files with funny names
that the operating system recognized and handled differently from
ordinary files when new members of the group were created.  There were
two ways a file in a GDG could be referred to, by absolute generation
number and by relative generation number.  A GDG file named 
FILENAME.G0017V00 was absolute generation 17 of the GDG named FILENAME.
Rarely was the absolute number used, however, since most procdefs
(similar to shell procedures) were written to use the relative numbers.
The current version of GDG FILENAME was referred to as FILENAME(0).
The previous version of FILENAME was referred to as FILENAME(-1).  When
a new version of FILENAME was created it was referred to as
FILENAME(+1) prior to being completely created, and became FILENAME(0)
when it was closed after being written.  When a new member joined a GDG
one or more of its predecessors was automatically deleted, according to
the option selected when the GDG was declared.  For example, one could
specify that no more than 3 generations were to be maintained, with the
oldest being removed when a new one was created.  This would keep many
generations of the file from accumulating.

How did this solve the problem described above?  When a user referenced
the program or data file, they requested relative generation 0 of that
file.  In this way they got the most current of the moment.  When we
created a new one, we named it relative generation +1 until it had been
written and closed.  At that point it became relative generation 0 and
the next user to request it would get this brand new generation.

				Rich Strebendt
				...!ihnp4![iwsl6|ihlpe|ihaxa]!res