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

Re: Issue 1509 - was WC Permissions

From: <kfogel_at_collab.net>
Date: 2003-12-11 16:32:43 CET

If this works, it sounds like a great solution.

However, this is definitely in the "too risky for 1.0" basket, IMHO,
and we shouldn't make the change until after the 1.0 release. Do you
mind waiting?

John Peacock <jpeacock@rowman.com> writes:
> I took a look at this issue and I think I may have a way to solve
> this problem.
>
> What I propose is that svn_io_set_file_read_write() itself be extended
> to try a little harder. If the existing directory would permit the
> file to be renamed and recreated (i.e., the group ownership of the
> directory would permit it), then after the first attempt to change
> READONLY fails, the code could then attempt to rename and
> copy/recreate the file with the correct perms.
>
> Specifically here, libsvn_subr/io.c:
>
> svn_error_t *
> svn_io_set_file_read_write (const char *path,
> svn_boolean_t ignore_enoent,
> apr_pool_t *pool)
> {
> apr_status_t status;
> const char *path_apr;
>
> SVN_ERR (svn_path_cstring_from_utf8 (&path_apr, path, pool));
>
> status = apr_file_attrs_set (path_apr,
> 0,
> APR_FILE_ATTR_READONLY,
> pool);
>
> if (status && status != APR_ENOTIMPL)
> if (!ignore_enoent || !APR_STATUS_IS_ENOENT(status))
>
> >>> this is where we could try harder
>
> return svn_error_createf (status, NULL,
> "svn_io_set_file_read_write: "
> "failed to set file '%s' read-write",
> path);
>
> Is this too low level a change??? What do you think???
>
> John
>
> --
> John Peacock
> Director of Information Research and Technology
> Rowman & Littlefield Publishing Group
> 4501 Forbes Boulevard
> Suite H
> Lanham, MD 20706
> 301-459-3366 x.5010
> fax 301-429-5748
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 17:21:49 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.