[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Showstopper bug in FS format file code

From: <kfogel_at_collab.net>
Date: 2005-04-11 17:40:23 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> In r13387 Karl added the following to svn_fs_fs__open:
> /* Read the FS format number. */
> err = svn_io_read_version_file (&format, path_format (fs, pool), pool);
> if (err && APR_STATUS_IS_ENOENT (err->apr_err))
> {
> /* Pre-1.2 filesystems did not have a format file (you could say
> they were format "0"), so they get upgraded on the fly. */
> svn_error_clear (err), err = NULL;
> SVN_ERR (svn_io_write_version_file
> (path_format (fs, pool), format, pool));
> }
> else if (err)
> return err;
> This has three problems:
> * We might not have write access to the repository, in which case we
> will error out inappropriately.
> * We might have a umask which would prevent other users from reading
> the new format file, which would cause them to error out
> inappropriately when they try to access it.
> * Philosophically, read-only operations on an FSFS repository should
> leave no trace, so even if we opportunistically try to create the
> FS format file and use appropriate permissions, we would be
> tarnishing the design.
> We can't release 1.2 with these problems.
> For the moment, I suggest treating an empty format file as being equal
> to an FS format of 1, without creating the format file. (If we need
> to actually bump the FS format in the future, we'll get into the same
> big argument about auto-upgrading as we did for the repository format
> file previously.)

Thanks for catching this, Greg. I'll fix it on trunk, in the way you
suggest above, and propose the fix for backport to 1.2.x.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 11 18:32:19 2005

This is an archived mail posted to the Subversion Dev mailing list.