Re: RCS file ownership?

athompso@athompso.net wrote:

> Heh, good point. Didn't even occur to me because as it happens, I am
> running as root and would like to not change the ownership.-Adam
> On Apr. 29, 2020 13:32, Anders Andersson <pipatron@gmail.com> wrote:
>
> On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson <athompso@athompso.net>
> wrote:
> >
> > When I use co(1) with "-l" to check out a file (and/or "ci -l") is
> there
> > any way to preserve file ownership and *not* have it reset to the
> user
> > running co(1) or ci(1)?
> > I don't see anything in rcs(1), co(1) or ci(1) that even mentions
> the
> > fact that the file will wind up owned by the user running the
> command.
> > Ideas? Pointers to documentation?
>
> How could it possibly do anything else unless you always run co as
> root?

Our rcs tools do:

52628 co RET kbind 0
52628 co CALL unlink(0x7f7ffffed1f3)
52628 co NAMI "ls.c"
52628 co RET unlink -1 errno 2 No such file or directory
52628 co CALL open(0x7f7ffffed1f3,0x601<O_WRONLY|O_CREAT|O_TRUNC>,0100444<S_IRUSR\
|S_IRGRP|S_IROTH|S_IFREG>)
52628 co NAMI "ls.c"
52628 co RET open 4
52628 co CALL kbind(0x7f7ffffec908,24,0x847da2a816b5d817)

Which appears to be this:

else {
(void)unlink(dst);

if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode)) == -1)
err(1, "%s", dst);

I don't know what older or gnu rcs do. I guess whichever way this is done
it must balance concerns between atomicity of concurrent reads performed
by earlier processes, versus replacement of a potentially active file.

If the latter is chosen, it would unlink(), perform the open more
carefully, check that it is in the right place with fstat, but then
it needs some work for ftruncate (to get rid of extra file contents
at the end). If the open() failed, it might try an unlink followed by
open()?

Other rcs implimentations need to be checked. It is better if they work
the same.