> -----Original Message-----
> From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> Sent: dinsdag 5 maart 2013 13:57
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1452780 -
> Author: stsp
> Date: Tue Mar 5 12:57:00 2013
> New Revision: 1452780
> URL: http://svn.apache.org/r1452780
> Address issue #4331, "working copy permissions change on commit for files
> with keywords" by preventing the accidental removal of existing permission
> bits set on files which undergo translation.
> This is not a perfect answer to the proposition given in the issue that
> "Committing a file should not change its permissions in the WC."
> Committed files may still get a new owner/group/other write bit set if
> the umask allows this and the file's properties indicate that the file must
> be set read-write (see svn_wc__sync_flags_with_props() which might tweak
> permission bits of the translated file). But I think this is acceptable.
> I'm not sure if never changing the permission bits of committed files is
> a realistic requirement. Changing this would require additional effort
> and might break other scenarios.
> * subversion/libsvn_subr/subst.c
> (svn_subst_copy_and_translate4): Copy file permissions from the source
> to the temporary file which stores the translated result. The temporary
> file might have stricter permissions than the source, due to the way
> our APIs for creating temporary files work. Removing permission bits from
> files during translation is an unwanted side effect and should be avoided.
> Modified: subversion/trunk/subversion/libsvn_subr/subst.c
> --- subversion/trunk/subversion/libsvn_subr/subst.c (original)
> +++ subversion/trunk/subversion/libsvn_subr/subst.c Tue Mar 5 12:57:00
> @@ -1743,7 +1743,12 @@ svn_subst_copy_and_translate4(const char
> /* Now that dst_tmp contains the translated data, do the atomic rename.
> - return svn_error_trace(svn_io_file_rename(dst_tmp, dst, pool));
> + SVN_ERR(svn_io_file_rename(dst_tmp, dst, pool));
> + /* Preserve the source file's permission bits. */
> + SVN_ERR(svn_io_copy_perms(src, dst, pool));
> + return SVN_NO_ERROR;
There is a possible race condition here, which might be resolved by copying the permissions before moving.
(But most likely you just get a different race condition by switching the order)
Received on 2013-03-05 14:08:05 CET