You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2006/10/18 22:16:32 UTC
Re: svn commit: r22026 - trunk/subversion/libsvn_fs_fs
Does this work on Windows? It has a reputation of being unable to do
stuff which Unix/POSIX systems can (such as unlinking open files)...
bye,
Erik.
On 10/19/06, malcolm@tigris.org <ma...@tigris.org> wrote:
> Author: malcolm
> Date: Wed Oct 18 15:14:54 2006
> New Revision: 22026
>
> Log:
> FSFS: Remove a small race that would allow writes to a prototype revision file
> in the period between the file's closure and moving the revision file into
> place.
>
> Review by: rooneg
>
> * subversion/libsvn_fs_fs/fs_fs.c
> (commit_body): Delay unlocking the prototype revision file until after it
> has been moved into place.
>
>
> Modified:
> trunk/subversion/libsvn_fs_fs/fs_fs.c
>
> Modified: trunk/subversion/libsvn_fs_fs/fs_fs.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_fs_fs/fs_fs.c?pathrev=22026&r1=22025&r2=22026
> ==============================================================================
> --- trunk/subversion/libsvn_fs_fs/fs_fs.c (original)
> +++ trunk/subversion/libsvn_fs_fs/fs_fs.c Wed Oct 18 15:14:54 2006
> @@ -4335,7 +4335,9 @@
> SVN_ERR(svn_io_file_flush_to_disk(proto_file, pool));
>
> SVN_ERR(svn_io_file_close(proto_file, pool));
> - SVN_ERR(unlock_proto_rev(cb->fs, cb->txn->id, proto_file_lockcookie, pool));
> + /* We don't unlock the prototype revision file immediately to avoid a
> + race with another caller writing to the prototype revision file
> + before we commit it. */
>
> /* Remove any temporary txn props representing 'flags'. */
> SVN_ERR(svn_fs_fs__txn_proplist(&txnprops, cb->txn, pool));
> @@ -4361,6 +4363,12 @@
> SVN_ERR(svn_fs_fs__move_into_place(proto_filename, rev_filename,
> old_rev_filename, pool));
>
> + /* Now that we've moved the prototype revision file out of the way,
> + we can unlock it (since further attempts to write to the file
> + will fail as it no longer exists). We must do this so that we can
> + remove the transaction directory later. */
> + SVN_ERR(unlock_proto_rev(cb->fs, cb->txn->id, proto_file_lockcookie, pool));
> +
> /* Update commit time to ensure that svn:date revprops remain ordered. */
> date.data = svn_time_to_cstring(apr_time_now(), pool);
> date.len = strlen(date.data);
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r22026 - trunk/subversion/libsvn_fs_fs
Posted by sv...@mobsol.be.
Quoting Erik Huelsmann <eh...@gmail.com>:
> Does this work on Windows? It has a reputation of being unable to do
> stuff which Unix/POSIX systems can (such as unlinking open files)...
>
Running basic_tests.py doesn't seem to give any problems. Let's see what the
Windows buildslave makes of it (you'll see in half an hour).
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r22026 - trunk/subversion/libsvn_fs_fs
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Oct 19, 2006 at 12:16:32AM +0200, Erik Huelsmann wrote:
> Does this work on Windows? It has a reputation of being unable to do
> stuff which Unix/POSIX systems can (such as unlinking open files)...
>
It certainly should. Note that when I say 'unlock the prototype
revision file' what I actually mean is 'unlock the rev-lock file and
unlock the transaction in the shared-memory section' (the rev-lock file
is what's important here). We don't actually lock the rev file itself,
so there should be no problem with that.
Regards,
Malcolm