> 
> cat(1) *is* a rather short program, though. In the grand scheme of things,
> it's not noticeably longer than either a cat(1)-wrapper or subset of cat(1)
> that obeys locks and appends to a file.

Mmmm.....
Ah, I see (having looked at the source for netbsd's cat), it
doesn't have all the optimisations for using mmap() on the source
file to save (at least) one copy of the data.
(Writing mmap()ed pages could actually remove all cpu based copies
of the data)


> > exec >file
> > echo line 1 | cat -l
> > echo line 2 | cat -l
> > 
> > without the unlock the second line probably blocks
> > (try this with your modified cat)
> 
> Works fine.
> 
> Once a process is finished, as I understand it, all its open file
> descriptors go away and things associated with its state, like locks, also
> go away. (I'm always open to correction, of course, but this certainly is
> how the system behaves.)

Ah - but file descriptors obtained with dup (and fork) share the same
'file' structure - which is where (ACTFM) the lock is applied.
(Maybe the system does remove locks when processes die - the FM doesn't
say)

> > (I still think writing entire lines with O_APPEND set is safer - especially
> > on random OS)
> 
> Safe... From what I can see, the only two things that modify METALOG are
> the lines we're addressing directly here, and install(1), which explicitly
> obeys advisory locks already.

Safer in the sence that the OS/FS will get O_APPEND right, but may not
get flock() right :-) (am I too pessimistec here?)

> > This is _supposed_ to be unnecessary; when the file descriptor is
> > closed on exit, all locks on it are supposed to be released.

This would be - 'all locks on the 'file' owned by the dying process'.

	David

-- 
David Laight: david@l8s.co.uk