On Fri, 2003-09-05 at 11:19, Marc Singer wrote:
> The BDB backend is a process running within the context of a user, no
> what operating system this happens to execute on. If the privilege of
> that user is insufficient to write to the database, any operations on
> the repository will fail. We can check for this kind of failure.
Aha, now I get it. I can further break this down into two kinds of
failure tests:
(1) The user has full access to the repository, but is not the same as
the owner of the repository, and has a umask of 022 or worse. So
accessing the repository would work fine, but would break things for the
next person to come along. (We can't just reset the umask because we're
a library and we can't muck with global process state like that, and we
can't munge the permissions of newly-created logfiles because Berkeley
DB has no support for that.) We would like to preemptively error out in
this case to avoid putting repositories into inconsistent states.
(2) The user does not have required access to the repository, perhaps
because of something like what I described in (1). We would like to
preemptively error out in this case so that people realize they have a
permissions problem and not a data corruption problem.
In addition to portability concerns (which are probably manageable), the
difficult part about writing tests for these failures is that we don't
want to violate the Berkeley DB abstraction. But BDB does have a
function to list all logfiles, so I think both tests are probably still
doable. So, +1. Someone should submit a patch or, failing that, file
an issue. Even if (2) turns out to be difficult, (1) shouldn't be very
hard, and that would solve 90% of the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 5 18:23:14 2003