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

RE: WIN32_RETRY_LOOP and opening read-only files for writing.

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 2 Mar 2010 20:38:40 +0100

> -----Original Message-----
> From: lieven.govaerts_at_gmail.com [mailto:lieven.govaerts_at_gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: maandag 1 maart 2010 16:29
> To: Subversion Development
> Subject: WIN32_RETRY_LOOP and opening read-only files for writing.
> Hi,
> I maintain some merge scripts written in Java that work with both
> SVNKit and JavaHL. During unit testing on Windows XP we noticed that
> some simple svn actions, like checkout take an extraordinary amount of
> time. E.g. 'svn checkout' over ra_local of a branch with 3 folders and
> 6 100 bytes files takes appr. 20 seconds.
> After some debugging we found that svn spends almost 15 seconds trying
> to change a simple username file in ~\Subversion\auth\svn.username
> (see attached extract of the Process Monitor log). It turns out this
> file already existed and was set read-only. When JavaHL/svn creates
> this file it makes it writeable, but SVNKit seems to create it as
> read-only - which I suspect is a bug in SVNKit.
> Looking at the Process Monitor output I suppose these 15 seconds are
> spent in WIN32_RETRY_LOOP, defined in libsvn_subr/io.c.
> WIN32_RETRY_LOOP tries in this case to open the file for writing, and
> gets an ERROR_ACCESS_DENIED error. Now I know this error can mean lots
> of things, so I don't propose to drop it altogether. But can't we add
> a check that, if svn gets this error during file opening, it checks
> first if the file is read-only before retrying 100 times?
> I see we already do something similar in svn_io_remove_file.
> Remarks?

+1 on adding that check before the first retry, like we do in a few other

(But please don't do some testing before the initial operation, as we do in
at least one place. This fallback should never be necessary on files we just
handle ourselves).

Received on 2010-03-02 20:39:17 CET

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