On Sun, Nov 01, 2009 at 09:59:25AM +0100, Stefan Sperling wrote:
> On Sun, Nov 01, 2009 at 03:23:29AM +0100, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2009-11-01 02:34:06 Arfrever Frehtes Taifersar Arahesis napisał(a):
> > > `svn co` (and `svn up`) creates files with wrong permissions. This problem
> > > doesn't occur with Subversion 1.6.x_at_HEAD, so it's a regression in trunk.
> > > I use Subversion trunk_at_40332.
> >
> > This regression has been introduced in r40264.
>
> This happens because we now use mkstemp() to create temporary files
> in many places, and mkstemp() locks down permissions to 0600. The temp
> file is then copied to the working copy and permissions aren't adjusted.
> So the (very old) bug you ran into is that instead of adjusting permissions,
> svn is using the permissions of the tempfile unaltered, even though those
> permissions might not make sense in the WC.
> Note that on win32 all files inherit their perms from their parent
> folder and we have no way to override this yet. So this problem only
> happens on UNIX.
>
> I ran into a similar problem before, see r40275. Specifically, see the change
> made to libsvn_wc/copy.c:copy_file_administratively in r40275. It shows an
> example of how the problem can be fixed by doing a single svn_io_copy_perms()
> call after installing the temp file in the working copy. If there is no
> source file to copy perms from (you can even pass NULL for 'src'), the
> destination will automatically get default permissions, which should honour
> the umask.
I have fixed the problem shown by your example script in r40333.
Thanks for catching this.
We may want to look for more places where temporary files end up being
installed in the working copy and make sure to always set permissions
properly. Anyone up for a bite-sized task like this? Scanning the code
or use of temporary files should give anticipating developers lots of
opportunity to learn.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413400
Received on 2009-11-01 11:14:09 CET