O_APPEND, 2nd try...

[Juergen Lock <nox@jelal.north.de>]

Stephen Usher writes:
> From oytix!olis.isc.north.de!arbi.informatik.uni-oldenburg.de!terminator.rs.itd.umich.edu!mint-request  Tue Aug 10 21:58:02 1993
> From: Stephen Usher <steve@earth.ox.ac.uk>
> Message-Id: <2653.9308100838@earth.ox.ac.uk>
> Subject: Latest version of my init(8) package.
> ...

 aah, so the list is still alive... :)  i haven't seen this back and
also also got no answer, so i guess i got lost somehow:

~From nox Fri Jul 30 00:23:14 1993
~Subject: Re: O_APPEND, file locking...
~To: schwab@ls5.informatik.uni-dortmund.de
~Date: Fri, 30 Jul 93 0:23:14 CES
~From: Juergen Lock <nox@jelal.north.de>
~Cc: mint@terminator.rs.itd.umich.edu
~In-Reply-To: <9307260845.AA11790@issan.informatik.uni-dortmund.de>; from "Andreas Schwab" at Jul 26, 93 10:45 am
~X-Mailer: ELM [version 2.3/ST PL11]
~Status: RO

Andreas Schwab writes:

> >>>>> On Fri, 23 Jul 93 20:35:44 CES, Juergen Lock <nox@jelal.north.de> said:
> |>  quick question: on what filesystems does O_APPEND (or fopen (.. "a"))
> |>  work with > 1 processes writing to the same file?  i doubt it does on
> |>  GEMDOSfs, but on others?  reason i ask is should i put locking code
> |>  around simple one-line fprintfs to logfiles.. i would rather not :-)
> 
> It works with every filesystem, because MiNT translates it to
> lseek(SEEK_END) + write, atomically.

 well here's what i found out now.  seems it works with every
filesystem except GEMDOS ones: (and i'm not surprised...)

-------cut----
# touch foo
	(file has to exist, see below)
# cat >>foo

%1 +    49 Stopped              cat >> foo 
	stop (^Z), foo is open now with O_APPEND...
# echo 1 >>foo
	appended 1 line
# fg
%1 +    49 Running              cat >> foo 
2
3
	back to first process: append 2 more lines, then EOF (^D)
# cat foo
2
3
	where is line 1??
# touch /f/foo
	now the same thing on a minixfs...
# cat >>/f/foo

%1 +    53 Stopped              cat >> /f/foo 
# echo 1 >>/f/foo
# fg
%1 +    53 Running              cat >> /f/foo 
2
3
# cat /f/foo
1
2
3
	ok!
# rm /f/foo
# cat >>/f/foo
	and now what happens when the file does not exist...

%1 +    56 Stopped              cat >> /f/foo 
# echo 1 >>/f/foo
/f/foo: cannot open
# kill %1
# 
%1 +    56 Terminated           cat >> /f/foo 
# 
-------cut----

 conclusions :-)

1. i think open should use Fopen not Fcreate on MiNT versions that
have O_CREAT in the kernel, then O_APPEND and file sharing modes etc
won't get lost.  (haven't tried but i think that was the reason for
`cannot open'...)

2. i'm quite sure what we have here is the old GEMDOS bug that it can't
really cope with 2 opens to the same file, another one that nobody
seems to believe me... (atleast it cant as soon as one starts writing.)
this is MiNT 1.07 (with patches), and TOS 2.05.

3. and here's the patch for ksh so it uses O_APPEND :-)

--- exec.c_3	Thu Jul  8 14:29:12 1993
+++ exec.c	Wed Jul 28 19:06:12 1993
@@ -856,11 +856,16 @@
 		break;
 
 	  case IOCAT:
+#ifdef O_APPEND
+		u = open(cp, O_WRONLY|O_CREAT|O_APPEND, 0666);
+		break;
+#else
 		if ((u = open(cp, 1)) >= 0) {
 			(void) lseek(u, (long)0, 2);
 			break;
 		}
 		/* FALLTHROUGH */
+#endif
 	  case IOWRITE:
 		u = creat(cp, 0666);
 		break;

 cheers,
	Juergen

PS: are there TOS (GEMDOS) versions that have the bug fixed?  can't be
before falcon TOS i assume...

PPS: now would _you_ prefer a shell where you don't have source? ;-)
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA