One of the last remaining edge cases for having shared working copies,
(Issue #1509), is setting the svn:executable bit. If the user does
not own the file, then setting the property directly or through an
update will fail. The only workaround for this is to move the old
file out of the way, then copy it back into place so as to change the
user owning the file. I have implemented a patch that accomplishes
this attached to this message.
The problem is that this can introduce data loss in a different
location than before. If some other user was editing a file when the
caller set the svn:executable property, that user's edits will be lost
as he is editing a file that has been deleted. Previously this could
only happen if an update received textual changes to the file.
In IRC, ghudson said:
> Yes. Given that "svn up" while editing is known not to be safe, I
> don't think we have a mandate to try to prevent data loss only some of
> the time in that situation, at the expense of making shared working
> copies work.
What does everyone else think?
-Josh
=========================================================
Issue #1509: Work around the fact that a user can't set executable
permissions on files they do not own by moving and copying the file
around to make it such that the current user does own the file.
* subversion/libsvn_subr/io.c
(reown_file): New, moves a file to a temporary location, then copies
it back so as to create a new version that is owned by the current
user.
(svn_io_set_file_executable): If the original permissions set fails
in the stat-available path, try again after having re-owned the
file. This assumes that the move-copy workaround will not be
useful on any systems that do not implement apr_stat.
Index: subversion/libsvn_subr/io.c
===================================================================
--- subversion/libsvn_subr/io.c (revision 10101)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -792,7 +792,28 @@
return SVN_NO_ERROR;
}
+/* Given the file specified by PATH_APR, attempt to create an
+ identical version of it owned by the current user. This is done by
+ moving it to a temporary location, copying the file back to its old
+ path, then deleting the temporarily moved version. All temporary
+ allocations are done in POOL. */
+static svn_error_t *
+reown_file (const char *path_apr,
+ apr_pool_t *pool)
+{
+ apr_file_t *fp;
+ const char *unique_name;
+ SVN_ERR (svn_io_open_unique_file (&fp, &unique_name, path_apr,
+ ".tmp", FALSE, pool));
+ SVN_ERR (svn_io_file_close (fp, pool));
+ SVN_ERR (svn_io_file_rename (path_apr, unique_name, pool));
+ SVN_ERR (svn_io_copy_file (unique_name, path_apr, TRUE, pool));
+ SVN_ERR (svn_io_remove_file (unique_name, pool));
+
+ return SVN_NO_ERROR;
+}
+
svn_error_t *
svn_io_set_file_executable (const char *path,
svn_boolean_t executable,
@@ -841,12 +862,28 @@
status = apr_file_perms_set (path_apr, perms_to_set);
if (status)
{
- if (ignore_enoent && APR_STATUS_IS_ENOENT (status))
+ if (status == EPERM)
+ {
+ /* We don't have permissions to change the
+ permissions! Try a move, copy, and delete
+ workaround to see if we can get the file owned by
+ us. If these succeed, try the permissions set
+ again. */
+ SVN_ERR (reown_file (path_apr, pool));
+ status = apr_file_perms_set (path_apr, perms_to_set);
+ }
+
+ if (status)
+ {
+ if (ignore_enoent && APR_STATUS_IS_ENOENT (status))
+ return SVN_NO_ERROR;
+ else if (status != APR_ENOTIMPL)
+ return svn_error_wrap_apr (status,
+ "Can't change executability of "
+ "file '%s'", path);
+ }
+ else
return SVN_NO_ERROR;
- else if (status != APR_ENOTIMPL)
- return svn_error_wrap_apr (status,
- "Can't change executability of "
- "file '%s'", path);
}
else
return SVN_NO_ERROR;
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 29 17:51:27 2004