Ok, here is the issue I think.
In 1.3.2 there was a function called
svn_io_set_file_read_write_carefully() that called the reown subroutine if needed. Reown does exactly what I did below :) Reown works for a multi-user (common group) working copy use case as we saw in the past.
1.4.* removed the _carefully function and added a new set of permission functions, one of which is svn_io_set_file_read_write(). This function calls io_set_file_perms() which uses reown - BUT ONLY FOR Win32.
So I guess I'd put the io_set_file_perms() call inside the apr_file_attrs_set status error failure execution branch. This should have zero impact on those using the "approved" usage model and give us fringe users the reown function back for the multi-user wc scenario.
I'm sending this to dev since this has moved beyond a usage topic.
Does anyone have any issues with attempting to call io_set_file_perms() if the apr_file_attrs_set fails?
Eric
> -----Original Message-----
> From: Bakke, Steven
> Sent: Friday, January 12, 2007 9:59 AM
> To: Miller, Eric
> Subject: Re: File permissions problems with 1.4.0 (yet again!)
>
> The argument for not just fixing this is that if you aren't careful, it
> would noticeably hurt performance for users that don't have this problem.
>
> I just now dug into the source code and found the routines that handle
> this.
> It would be simple to fix the problem. I just wonder if we could create a
> patch and convince them to take it?
>
> The relevant file from the 1.4.2 source tarball are:
>
> subversion/libsvn_subr/io.c
>
> Two functions of interest - svn_io_set_file_read_write() and
> svn_io_set_file_read_only().
>
> My thought was treat it like an exception. Don't do the special
> workaround
> unless the original attempt fails. Then go through the process of
> changing
> file ownership followed by re-attempting the permissions change.
>
> I think fixing it ourselves would be the best way to get the change made
> in
> the regular source code. I would hope that doing the change and then
> presenting benchmark data to prove that you didn't kill performance for
> the
> general case would be sufficient.
>
> What do you think?
>
> -Steve
>
>
> On 1/12/07 11:45 AM, "Miller, Eric" <Eric.Miller@amd.com> wrote:
>
> > I have never understood why you can't chown a file that you can
> delete...
> >
> > User A: touch i
> > User A: echo "omg! plz dnt ch0w|\| t|-|i5" >> i
> >
> > User B: ls -lad . i
> > drwxrwxr-x 6 A design 4096 Jan 12 08:35 .
> > -r--r--r-- 1 A design 28 Jan 12 08:31 i
> >
> > User B: chown userb i
> > chown: changing ownership of `i': Operation not permitted
> >
> > User B: cp i i.tmp
> > User B: rm -f i
> > User B: mv i.tmp i
> > User B: ls -la i
> > -rw-r--r-- 1 B design 28 Jan 12 08:42 i
> >
> > Tada!
> >
> >> -----Original Message-----
> >> From: Steve Bakke [mailto:steven.bakke@amd.com]
> >> Sent: Friday, January 12, 2007 9:11 AM
> >> To: users@subversion.tigris.org
> >> Subject: Re: File permissions problems with 1.4.0 (yet again!)
> >>
> >> Sorry, but my first paragraph got chopped off somehow... Continueing
> the
> >> last sentence.
> >>
> >> It is probably only in a minority of setups that people would use file
> >> lock/unlock. The way that subversion has been set up to work, a lock
> >> operation makes a file writeable and the unlock operation makes it
> >> read-only. The presence or absence of a lock is intended to
> communicate
> >> when somebody is editing in a different work area. It really ought to
> >> handle file ownership and permissions properly if it is going to be
> >> changing
> >> permissions in the first place.
> >>
> >> -Steve
> >>
> >> On 1/12/07 11:06 AM, "Steve Bakke" <steven.bakke@amd.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> In a previous set of posts, I described problems I was having with svn
> >>> lock/unlock not handling file ownership in version 1.4.x. Because you
> >> need to
> >>> own a file in order to make it read-only, subversion will not unlock
> or
> >> lock a
> >>> file that is owned by another user. This is in a case where all of
> the
> >>> directories have proper group Œrwx¹ permissions. The consensus of the
> >> few who
> >>> responded was that my usage model is flawed. My response to that is
> >> that in
> >>> the case you are using file lock/unlock,
> >>>
> >>> I have now run into another problem related to the same issue. This
> >> time, it
> >>> is related to committing files which have been locally added with the
> >>> needs-lock property. Here is the sequence of events:
> >>> 1. User A copies some new files into a working copy.
> >>> 2. User B runs Œsvn add¹ on these. So far so good...
> >>> 3. User B tries to run Œsvn commit¹ on the added files.
> >>>
> >>> Step three actually goes through 95% of the commit process and
> actually
> >> sends
> >>> the data to the server. Finally, when the svn client attempts to
> change
> >> the
> >>> file permissions on the files with needs-lock, the whole commit fails
> >> because
> >>> it can't change permissions. User A owned the file.
> >>>
> >>> Correct me if I'm wrong, but commits are supposed to be atomic,
> correct?
> >> If
> >>> my commit fails, I would have thought that the repository should not
> >> have a
> >>> new committed revision. However, if I try to have User B commit these
> >>> results, it then fails because it says the files already exist in the
> >>> repository. Now my working copy is seemingly corrupted since all of
> the
> >> files
> >>> have 'A' status, yet they actually got checked in.
> >>>
> >>> Could somebody please help me here?
> >>>
> >>> I would really like to file a bug on the file lock/unlock ownership
> >> issue.
> >>> Why should this not be fixed? I believe it could be done without
> >> impacting
> >>> working copy performance of those who don't have mixed file ownerships
> >> in the
> >>> working copy.
> >>>
> >>> Thanks,
> >>>
> >>> Steve Bakke
> >>>
> >>> p.s. At what point can I just go ahead and submit a bug on an issue?
> >> Just
> >>> because people don¹t agree with my particular usage model doesn¹t mean
> >> that
> >>> there isn¹t a bug in subversion. It At a minimum, I think it would
> be
> >> useful
> >>> to document real bugs even if the development team chooses not to fix
> >> the
> >>> problem.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: users-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 Fri Jan 12 18:47:11 2007