[9fans] changing file ownership with fossil?

[9fans] changing file ownership with fossil?

[Tim Fraser]

Another newbie question for you all: how does one ask fossil to serve
a filesystem in a mode that allows one to change file ownerships?  The
fossil(8) man page suggests that one might:

term% con /srv/fscons
prompt: fsys main
main: srv -APW admin

where the -W flag is supposed to allow ownership changes.  However, at
least with my version of the software, the -W flag is not a valid
option when entered as I have shown above.  Where have I gone wrong?

Some details:

I originally installed from a CD-ROM downloaded 29 Sept 2003, and last
ran replica/pull over the network on 12 October 2003.  The pull warned
me that it left many files owned by glenda, and I was subsequently
unable to chgrp -o them to sys.

Thanks to David Presotto for introducing me to /srv/fscons.  Further
thanks to mirtchov for showing how to modify /dist/replica/network for
use with fossil.

Tim Fraser / U. Maryland Institute for Advanced Computer Studies

Re: [9fans] changing file ownership with fossil?

[jmk]

An oversight. I've tried to fix it (untested) and correct the man page.
New source and man page on sources.

On Mon Oct 13 20:21:50 EDT 2003, tfraser@cs.umd.edu wrote:
> Another newbie question for you all: how does one ask fossil to serve
> a filesystem in a mode that allows one to change file ownerships?  The
> fossil(8) man page suggests that one might:
>
> term% con /srv/fscons
> prompt: fsys main
> main: srv -APW admin
>
> where the -W flag is supposed to allow ownership changes.  However, at
> least with my version of the software, the -W flag is not a valid
> option when entered as I have shown above.  Where have I gone wrong?
>
> Some details:
>
> I originally installed from a CD-ROM downloaded 29 Sept 2003, and last
> ran replica/pull over the network on 12 October 2003.  The pull warned
> me that it left many files owned by glenda, and I was subsequently
> unable to chgrp -o them to sys.
>
> Thanks to David Presotto for introducing me to /srv/fscons.  Further
> thanks to mirtchov for showing how to modify /dist/replica/network for
> use with fossil.
>
> Tim Fraser / U. Maryland Institute for Advanced Computer Studies

Re: [9fans] changing file ownership with fossil?

[Tim Fraser]

jmk> An oversight. I've tried to fix it (untested) and correct the man
jmk> page.  New source and man page on sources.

Thank you for your rapid response.  I re-ran replica/pull around
22:00EST on 14 October 2003 and was happy to see the new fossil binary
and sources download.  Unfortunately, I was once again unable to use
the -W flag.  A transcript:

term% con /srv/fscons
prompt: fsys main
main: srv -APW admin
usage: srv [-Adp] [service]
main: srv -AP admin
main: >>> q
term% mount /srv/admin /mnt/admin
term% lc -l /mnt/admin/386/bin/fossil/fossil
--rwxrwxr-x M 36 glenda sys 345764 Oct 13 22:22 fossil
term% chgrp -o sys /mnt/admin/386/bin/fossil/fossil
chgrp: can't wstat /mnt/admin/386/bin/fossil/fossil: wstat -- not owner

I have also experienced another problem that may be related:  While
using the 29 September and 12 October versions of fossil in -AP mode,
in addition to warnings about failures to set uids, I also witnessed
warnings like this one:

warning: cannot set mtime on /mnt/admin/sys/src/cmd/fossil/9srv.c

(This problem seems to be confined to source files, not binaries.)

At the time, I wasn't too concerned.  But, when I did my latest
replica/pull to acquire your changes to fossil, I found replica
refusing to update some files:

sys/src/cmd/fossil/9user.c: locally modified; will not update

I have not modified these files.  Is this refusal the result of
replica/pull's earlier failure to set the mtimes on these files?

Once again, thank you for your assistance!

Tim Fraser / U. Maryland Institute for Advanced Computer Studies

Re: [9fans] changing file ownership with fossil?

[Russ Cox]

> Thank you for your rapid response.  I re-ran replica/pull around
> 22:00EST on 14 October 2003 and was happy to see the new fossil binary
> and sources download.  Unfortunately, I was once again unable to use
> the -W flag.  A transcript:

Did you recompile the kernel?  Fossil is compiled into the kernel
and started at boot time, so you'd have to rebuild the kernel to
get it going.

	cd /sys/src/9/pc
	mk 'CONF=pcf' 9pcf
	9fat:
	cp 9pcf /n/9fat/9pcf2
	acme -c1 /n/9fat/plan9.ini

and find the line

	bootfile=sdC0!9fat!9pcf

and add

	bootfile=sdC0!9fat!9pcf2

then when you boot you'll be asked which kernel you want.

> I have also experienced another problem that may be related:  While
> using the 29 September and 12 October versions of fossil in -AP mode,
> in addition to warnings about failures to set uids, I also witnessed
> warnings like this one:
>
> warning: cannot set mtime on /mnt/admin/sys/src/cmd/fossil/9srv.c

That's weird.  Are you sure it was in -AP mode?  Can you use
touch successfully on those files?

> (This problem seems to be confined to source files, not binaries.)
>
> At the time, I wasn't too concerned.  But, when I did my latest
> replica/pull to acquire your changes to fossil, I found replica
> refusing to update some files:
>
> sys/src/cmd/fossil/9user.c: locally modified; will not update
>
> I have not modified these files.  Is this refusal the result of
> replica/pull's earlier failure to set the mtimes on these files?

Yes.

Russ

Re: [9fans] changing file ownership with fossil?

[Charles Forsyth]

there are changes for -W in several fossil files, including 9srv.c,
and pull probably didn't update that one.  less clear is why
the updated binary didn't work, unless that too isn't up to date.
you could cmp yours against sources.

replica checks the mtime and length to decide that a file
has changed, so if it couldn't set mtime correctly in a previous run,
things might well go wrong in a subsequent one.

by coincidence, for something i am doing,
i was going to change replica/applylog to
allow an optional extra field containing a hash of a file,
to allow more accurate detection of changes.
i was also trying to decide whether the database
was really needed.

Re: [9fans] changing file ownership with fossil?

[Russ Cox]

> i was also trying to decide whether the database
> was really needed.

without the database you only have two pieces
of information per file -- the mtime/length on the
local system and the mtime/length on the remote system.
a comparison between these two can only have two
outcomes, whereas there are three outcomes in the current
system:

	- file is outdated, needs updating
	- file is fine, no updating
	- file is outdated but locally changed, warn user

by storing a complete history of files given out
on the server, you could avoid storing the local
information, but that requires the server knowing
more about its clients than it currently does.
right now the per-client data is all on the clients,
and the server is "stateless" as it were.
(the database on the server could be
removed if you redefine mtime on directories
properly.)