rogers%albany.csnet@CSNET-RELAY.ARPA (Prof. Alan Rogers) (04/25/85)
> UNIX 4.2 allows files to be opened in append mode. I would > like to know if this is "Atomic Append". > > For example, if two programs open the same file in append mode, > and append few blocks to the file then is it true that the blocks > will be appended in order (that is first all the blocks of first > program followed by the blocks of the second program, or vice-versa). The other day I had two processes appending to the same file by mistake (BDS4.2). The first process wrote a few lines, and then these were overwritten by the the second process. When both were finished, the output of the first process had disappeared.
tanner@ki4pv.UUCP (Tanner Andrews) (05/03/85)
Opening for append using [see] fopen(3) does not cause anything of great magic to happen to the op system. The basic procedure involved is: (1) open file (2) seek to end (3) fill buffer and write to file in current position Consider the case for more than one process happening at once: Of course, if you have two people that open the file and seek to the end, both will seek to the SAME end. Then, when they start their output, the output will go to the same place. The guy that gets there LAST wins, of course. Of course you may get the same effect by using [see] open(2) and [see] lseek(2) to the end of the file, then writing. The result still probably isn't what you had in mind. -- <standard disclaimers apply, copies upon request> Tanner Andrews, KI4PV
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (05/05/85)
> Opening for append using [see] fopen(3) does not cause anything > of great magic to happen to the op system. The basic procedure > involved is: > ... NO! O_APPEND is enforced inside the kernel and causes true append, atomic within reasonable sizes of write requests. Several processes can append to the same file without clobbering each others' records. Indeed, that is why O_APPEND was invented.
guy@sun.uucp (Guy Harris) (05/09/85)
> Opening for append using [see] fopen(3) does not cause anything > of great magic to happen to the op system. The basic procedure > involved is: > (1) open file > (2) seek to end > (3) fill buffer and write to file in current position Not in System V. In System V, opening for append using "fopen" *does* turn on the "forced append" bit for the underlying file descriptor. This solves the problem you mention of two processes appending to the same file. (For System III or 4.NBSD for N >= 2, which have the same forced append bit but don't use it in the standard I/O library, #include <fcntl.h> int fdflags; if ((fdflags = fcntl(fileno(stream), F_GETFD, 0) < 0) { perror("Hell just froze over"); exit(69); } if (fcntl(fileno(stream), F_SETFD, fdflags|O_APPEND) < 0) { perror("The Mets just won the World Series"); /* * No statement is being made here about the relative * probability of the two "fcntl" calls failing :-) */ exit(17); } should do the trick. Guy Harris
tanner@ki4pv.UUCP (Tanner Andrews) (05/12/85)
It is also important to be sure that I/O is not buffered. Consider the problem of a "forced append" of 7/69ths of "fprintf()" output, with the rest being buffered. Then, some unlucky slime comes along and fills (and dumps, with forced append) his buffer. Right after 7/69ths of your fprintf(). Want to [see] kill(2) him, don't you? If you must use buffered I/O to append, create some lock file like "/tmp/LCK__prog" with proper protection modes while you work your will on the file. Forget to remove the lock file when done, and watch the fun begin. -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner