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

Re: [PATCH] Working copy on Samba share

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sun, 5 Oct 2008 14:50:26 +0300 (Jerusalem Daylight Time)

Ping, anyone has an opinion on this patch?

Alan: using empty lines between paragraphs helps people read what you
write (increasing the chance to get a response).

Daniel

alan.wood_at_clear.net.nz wrote on Mon, 22 Sep 2008 at 23:42 +1200:
> Hi All,
> I have been working on trying to make subversion working copies
> behave on Samba shares.
> This patch seems to solve two issues that I have seen.
> The problems happen after a commit when the working copy is being
> updated.
> The first is that a rename would sometimes fail from .svn/tmp/blah
> to .svn/blah2 or .svn/dir-props to .svn/dir-props-base
> The second fault would be cannot access dir/.svn/lock. Both would
> report 'permission denied'.
> I have managed to trace this to places in the code where
> GetFileAttributes and SetFileAttributes are called.
> Both of these functions suffer from the same fate as described at
> the top of io.c and which the macro WIN32_RETRY_LOOP() was written
> to alleviate.
> The FileAttribue calls are in the apr_ routines apr_stat() and
> apr_file_attrs_set().
> This patch wraps these two apr_ routines in the WIN32_RETRY_LOOP()
> macro.
> I have patched all uses of these two routines even though I have
> only managed to trace issues occurring in
> svn_io_set_file_read_write() called from svn_io_file_rename() and
> io_check_path().
> Tests so far confirm that the issues that I have been able to
> reproduce have disappeared.
>
> Alan Wood
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-05 17:48:42 CEST

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.