You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mathias Weinert <we...@mccw.de> on 2011/07/20 14:59:23 UTC
Problems with transaction file "next-ids" on Windows
Hi,
each time when I am loading a certain dump file on Windows which
contains one revision with over 100K changed paths I get the error
"Can't open file
'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
requested operation cannot be performed on a file with a user-mapped
section open.". After looking at the mailing list archives and other
mailing lists I found out that I am not the only one to encounter this
problem and that in most cases a virus scanner was the cause of the
problem. And indeed, adding next-ids to the exclusion list solved the
problem.
But now I wonder if svnadmin couldn't handle this case a bit more
elegantly. IMHO it would make sense not to quit the load immediately
but to try it again maybe after waiting half a second or so if this
specific error occurs (some other users reported that they got the
error "The process cannot access the file because it is being used by
another process."). If we can't access next-ids after trying it let's
say 5 times with a little pause after each try we still can quit the
load process.
What do you think about this idea?
Cheers,
Mathias
Re: Problems with transaction file "next-ids" on Windows
Posted by Mathias Weinert <we...@mccw.de>.
On Mon, 08 Aug 2011 07:39:06 +0200, Mathias Weinert wrote:
> Philip Martin <ph...@wandisco.com> wrote on Thu, 04 Aug 2011
> 14:58:53 +0100:
>
>> Mathias Weinert <we...@mccw.de> writes:
>>
>>> Philip Martin <ph...@wandisco.com> wrote:
>>>
>>>> Looking at this again, the call to svn_io_file_open already has a
>>>> retry
>>>> loop, so the original error seems to imply that either a) the file
>>>> is in
>>>> use for more than the retry delay or that b) there is some error
>>>> code
>>>> missing from the retry logic.
>>>
>>> Maybe we should add ERROR_USER_MAPPED_FILE to the retry logic (see
>>> attached patch).
>>>
>>> BTW the problem only occurs when using Windows svnadmin but not
>>> when
>>> using cygwin svnadmin (both executed in the same environment) (on
>>> cygwin another retry_loop is used which uses different error
>>> codes).
>>>
>>> Unfortunately I can't test the proposed change as I don't have an
>>> environment to build Subversion on Windows (without using cygwin).
>>>
>>> --- subversion/libsvn_subr/io.c.orig 2011-08-04 15:16:10.723195200
>>> +0200
>>> +++ subversion/libsvn_subr/io.c 2011-08-04 15:18:29.270766000 +0200
>>> @@ -131,7 +131,8 @@
>>> #define WIN32_RETRY_LOOP(err, expr)
>>> \
>>> RETRY_LOOP(err, expr, (os_err == ERROR_ACCESS_DENIED
>>> \
>>> || os_err == ERROR_SHARING_VIOLATION
>>> \
>>> - || os_err == ERROR_DIR_NOT_EMPTY),
>>> \
>>> + || os_err == ERROR_DIR_NOT_EMPTY
>>> \
>>> + || os_err == ERROR_USER_MAPPED_FILE),
>>> \
>>> 1)
>>> #else
>>> #define WIN32_RETRY_LOOP(err, expr) ((void)0)
>>
>> That does look like the right sort of thing. Any of our Windows
>> developers want to take a look?
>
> I am willing to test it if someone provided me an svnadmin.exe.
I am still willing to test this, but I need svnadmin and dlls or a
static version of svnadmin compiled for Windows (not cygwin).
Or maybe a Windows developer can test it himself.
As already written earlier, searching the web shows that I am not the
only one having this problem.
Re: [SVNDev] Re: Problems with transaction file "next-ids" on
Windows
Posted by Mathias Weinert <we...@mccw.de>.
Philip Martin <ph...@wandisco.com> wrote on Thu, 04 Aug 2011
14:58:53 +0100:
> Mathias Weinert <we...@mccw.de> writes:
>
>> Philip Martin <ph...@wandisco.com> wrote:
>>
>>> Looking at this again, the call to svn_io_file_open already has a retry
>>> loop, so the original error seems to imply that either a) the file is in
>>> use for more than the retry delay or that b) there is some error code
>>> missing from the retry logic.
>>
>> Maybe we should add ERROR_USER_MAPPED_FILE to the retry logic (see
>> attached patch).
>>
>> BTW the problem only occurs when using Windows svnadmin but not when
>> using cygwin svnadmin (both executed in the same environment) (on
>> cygwin another retry_loop is used which uses different error codes).
>>
>> Unfortunately I can't test the proposed change as I don't have an
>> environment to build Subversion on Windows (without using cygwin).
>>
>> --- subversion/libsvn_subr/io.c.orig 2011-08-04 15:16:10.723195200 +0200
>> +++ subversion/libsvn_subr/io.c 2011-08-04 15:18:29.270766000 +0200
>> @@ -131,7 +131,8 @@
>> #define WIN32_RETRY_LOOP(err, expr)
>> \
>> RETRY_LOOP(err, expr, (os_err == ERROR_ACCESS_DENIED
>> \
>> || os_err == ERROR_SHARING_VIOLATION
>> \
>> - || os_err == ERROR_DIR_NOT_EMPTY),
>> \
>> + || os_err == ERROR_DIR_NOT_EMPTY
>> \
>> + || os_err == ERROR_USER_MAPPED_FILE),
>> \
>> 1)
>> #else
>> #define WIN32_RETRY_LOOP(err, expr) ((void)0)
>
> That does look like the right sort of thing. Any of our Windows
> developers want to take a look?
I am willing to test it if someone provided me an svnadmin.exe.
Re: Problems with transaction file "next-ids" on Windows
Posted by Philip Martin <ph...@wandisco.com>.
Mathias Weinert <we...@mccw.de> writes:
> Philip Martin <ph...@wandisco.com> wrote:
>
>> Looking at this again, the call to svn_io_file_open already has a retry
>> loop, so the original error seems to imply that either a) the file is in
>> use for more than the retry delay or that b) there is some error code
>> missing from the retry logic.
>
> Maybe we should add ERROR_USER_MAPPED_FILE to the retry logic (see
> attached patch).
>
> BTW the problem only occurs when using Windows svnadmin but not when
> using cygwin svnadmin (both executed in the same environment) (on
> cygwin another retry_loop is used which uses different error codes).
>
> Unfortunately I can't test the proposed change as I don't have an
> environment to build Subversion on Windows (without using cygwin).
>
> --- subversion/libsvn_subr/io.c.orig 2011-08-04 15:16:10.723195200 +0200
> +++ subversion/libsvn_subr/io.c 2011-08-04 15:18:29.270766000 +0200
> @@ -131,7 +131,8 @@
> #define WIN32_RETRY_LOOP(err, expr) \
> RETRY_LOOP(err, expr, (os_err == ERROR_ACCESS_DENIED \
> || os_err == ERROR_SHARING_VIOLATION \
> - || os_err == ERROR_DIR_NOT_EMPTY), \
> + || os_err == ERROR_DIR_NOT_EMPTY \
> + || os_err == ERROR_USER_MAPPED_FILE), \
> 1)
> #else
> #define WIN32_RETRY_LOOP(err, expr) ((void)0)
That does look like the right sort of thing. Any of our Windows
developers want to take a look?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems with transaction file "next-ids" on Windows
Posted by Mathias Weinert <we...@mccw.de>.
Philip Martin <ph...@wandisco.com> wrote:
> Mathias Weinert <we...@mccw.de> writes:
>
>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>
>>> Philip Martin wrote on Wed, Jul 20, 2011 at 15:12:51 +0100:
>>>> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>>>>
>>>> > Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
>>>> >>
>>>> >> each time when I am loading a certain dump file on Windows which
>>>> >> contains one revision with over 100K changed paths I get the error
>>>> >> "Can't open file
>>>> >> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
>>>> >> requested operation cannot be performed on a file with a user-mapped
>>>> >> section open.".
>
>>>> The current implementation writes the file inplace:
>>>>
>>>> static svn_error_t *
>>>> write_next_ids(svn_fs_t *fs,
>>>> const char *txn_id,
>>>> const char *node_id,
>>>> const char *copy_id,
>>>> apr_pool_t *pool)
>>>> {
>>>> apr_file_t *file;
>>>> svn_stream_t *out_stream;
>>>>
>>>> SVN_ERR(svn_io_file_open(&file, path_txn_next_ids(fs, txn_id, pool),
>>>> APR_WRITE | APR_TRUNCATE,
>>>> APR_OS_DEFAULT, pool));
>>>>
>>>> out_stream = svn_stream_from_aprfile2(file, TRUE, pool);
>>>>
>>>> SVN_ERR(svn_stream_printf(out_stream, pool, "%s %s\n", node_id,
>>>> copy_id));
>>>>
>>>> SVN_ERR(svn_stream_close(out_stream));
>>>> return svn_io_file_close(file, pool);
>>>> }
>>>>
>>>> Is there any reason we don't switch to our standard pattern: write to a
>>>> temp file and rename? That would give us Subversion's standard retry
>>>> loop -- would that fix "requested operation cannot be performed"?
>
>> I replaced svn_io_file_open, svn_stream_printf and svn_stream_close
>> with svn_io_write_unique and move_into_place (see attached patch).
>> Although this works correctly it shows bad performance. Loading a dump
>> from a little repo which mainly has a 2000 files commit now takes
>> about 400s while with the original version it only took about 100s.
>
> svn_io_write_unique flushes to disk (except 1.7 on Windows) so that
> probably explains the slowdown.
>
> Looking at this again, the call to svn_io_file_open already has a retry
> loop, so the original error seems to imply that either a) the file is in
> use for more than the retry delay or that b) there is some error code
> missing from the retry logic.
Maybe we should add ERROR_USER_MAPPED_FILE to the retry logic (see
attached patch).
BTW the problem only occurs when using Windows svnadmin but not when
using cygwin svnadmin (both executed in the same environment) (on
cygwin another retry_loop is used which uses different error codes).
Unfortunately I can't test the proposed change as I don't have an
environment to build Subversion on Windows (without using cygwin).
Re: [SVNDev] Re: Problems with transaction file "next-ids" on Windows
Posted by Philip Martin <ph...@wandisco.com>.
Mathias Weinert <we...@mccw.de> writes:
> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
>> Philip Martin wrote on Wed, Jul 20, 2011 at 15:12:51 +0100:
>>> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>>>
>>> > Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
>>> >>
>>> >> each time when I am loading a certain dump file on Windows which
>>> >> contains one revision with over 100K changed paths I get the error
>>> >> "Can't open file
>>> >> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
>>> >> requested operation cannot be performed on a file with a user-mapped
>>> >> section open.".
>>> The current implementation writes the file inplace:
>>>
>>> static svn_error_t *
>>> write_next_ids(svn_fs_t *fs,
>>> const char *txn_id,
>>> const char *node_id,
>>> const char *copy_id,
>>> apr_pool_t *pool)
>>> {
>>> apr_file_t *file;
>>> svn_stream_t *out_stream;
>>>
>>> SVN_ERR(svn_io_file_open(&file, path_txn_next_ids(fs, txn_id, pool),
>>> APR_WRITE | APR_TRUNCATE,
>>> APR_OS_DEFAULT, pool));
>>>
>>> out_stream = svn_stream_from_aprfile2(file, TRUE, pool);
>>>
>>> SVN_ERR(svn_stream_printf(out_stream, pool, "%s %s\n", node_id, copy_id));
>>>
>>> SVN_ERR(svn_stream_close(out_stream));
>>> return svn_io_file_close(file, pool);
>>> }
>>>
>>> Is there any reason we don't switch to our standard pattern: write to a
>>> temp file and rename? That would give us Subversion's standard retry
>>> loop -- would that fix "requested operation cannot be performed"?
> I replaced svn_io_file_open, svn_stream_printf and svn_stream_close
> with svn_io_write_unique and move_into_place (see attached patch).
> Although this works correctly it shows bad performance. Loading a dump
> from a little repo which mainly has a 2000 files commit now takes
> about 400s while with the original version it only took about 100s.
svn_io_write_unique flushes to disk (except 1.7 on Windows) so that
probably explains the slowdown.
Looking at this again, the call to svn_io_file_open already has a retry
loop, so the original error seems to imply that either a) the file is in
use for more than the retry delay or that b) there is some error code
missing from the retry logic.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems with transaction file "next-ids" on Windows
Posted by Mathias Weinert <we...@mccw.de>.
Mathias Weinert <we...@mccw.de> wrote:
> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
>> Philip Martin wrote on Wed, Jul 20, 2011 at 15:12:51 +0100:
>>> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>>>
>>>> Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
>>>>>
>>>>> each time when I am loading a certain dump file on Windows which
>>>>> contains one revision with over 100K changed paths I get the error
>>>>> "Can't open file
>>>>> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
>>>>> requested operation cannot be performed on a file with a user-mapped
>>>>> section open.". After looking at the mailing list archives and other
>>>>> mailing lists I found out that I am not the only one to encounter
>>>>> this problem and that in most cases a virus scanner was the cause of
>>>>> the problem. And indeed, adding next-ids to the exclusion list
>>>>> solved the problem.
>>>>>
>>>>> But now I wonder if svnadmin couldn't handle this case a bit more
>>>>> elegantly. IMHO it would make sense not to quit the load immediately
>>>>> but to try it again maybe after waiting half a second or so if this
>>>>> specific error occurs (some other users reported that they got the
>>>>> error "The process cannot access the file because it is being used
>>>>> by another process."). If we can't access next-ids after trying it
>>>>> let's say 5 times with a little pause after each try we still can
>>>>> quit the load process.
>>>>
>>>> It would be good to solve this now as that is one of the concerns with
>>>> the (partially implemented) design for revprop packing, due for release
>>>> in 1.8.
>>>
>>> The current implementation writes the file inplace:
>>>
>>> static svn_error_t *
>>> write_next_ids(svn_fs_t *fs,
>>> const char *txn_id,
>>> const char *node_id,
>>> const char *copy_id,
>>> apr_pool_t *pool)
>>> {
>>> apr_file_t *file;
>>> svn_stream_t *out_stream;
>>>
>>> SVN_ERR(svn_io_file_open(&file, path_txn_next_ids(fs, txn_id, pool),
>>> APR_WRITE | APR_TRUNCATE,
>>> APR_OS_DEFAULT, pool));
>>>
>>> out_stream = svn_stream_from_aprfile2(file, TRUE, pool);
>>>
>>> SVN_ERR(svn_stream_printf(out_stream, pool, "%s %s\n", node_id, copy_id));
>>>
>>> SVN_ERR(svn_stream_close(out_stream));
>>> return svn_io_file_close(file, pool);
>>> }
>>>
>>> Is there any reason we don't switch to our standard pattern: write to a
>>> temp file and rename? That would give us Subversion's standard retry
>>> loop -- would that fix "requested operation cannot be performed"?
>>
>> fs_fs.c:move_into_file() already does the rename loop, so no objection.
>> (assuming we document that the use of move_into_file() is for
>> performance and virus scanners rather than for concurrent reader
>> correctness)
>>
>
> I replaced svn_io_file_open, svn_stream_printf and svn_stream_close
> with svn_io_write_unique and move_into_place (see attached patch).
> Although this works correctly it shows bad performance. Loading a
> dump from a little repo which mainly has a 2000 files commit now
> takes about 400s while with the original version it only took about
> 100s.
It was 20,000 files, not 2000.
Re: [SVNDev] Re: Problems with transaction file "next-ids" on
Windows
Posted by Mathias Weinert <we...@mccw.de>.
Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Philip Martin wrote on Wed, Jul 20, 2011 at 15:12:51 +0100:
>> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>>
>> > Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
>> >>
>> >> each time when I am loading a certain dump file on Windows which
>> >> contains one revision with over 100K changed paths I get the error
>> >> "Can't open file
>> >> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
>> >> requested operation cannot be performed on a file with a user-mapped
>> >> section open.". After looking at the mailing list archives and other
>> >> mailing lists I found out that I am not the only one to encounter
>> >> this problem and that in most cases a virus scanner was the cause of
>> >> the problem. And indeed, adding next-ids to the exclusion list
>> >> solved the problem.
>> >>
>> >> But now I wonder if svnadmin couldn't handle this case a bit more
>> >> elegantly. IMHO it would make sense not to quit the load immediately
>> >> but to try it again maybe after waiting half a second or so if this
>> >> specific error occurs (some other users reported that they got the
>> >> error "The process cannot access the file because it is being used
>> >> by another process."). If we can't access next-ids after trying it
>> >> let's say 5 times with a little pause after each try we still can
>> >> quit the load process.
>> >
>> > It would be good to solve this now as that is one of the concerns with
>> > the (partially implemented) design for revprop packing, due for release
>> > in 1.8.
>>
>> The current implementation writes the file inplace:
>>
>> static svn_error_t *
>> write_next_ids(svn_fs_t *fs,
>> const char *txn_id,
>> const char *node_id,
>> const char *copy_id,
>> apr_pool_t *pool)
>> {
>> apr_file_t *file;
>> svn_stream_t *out_stream;
>>
>> SVN_ERR(svn_io_file_open(&file, path_txn_next_ids(fs, txn_id, pool),
>> APR_WRITE | APR_TRUNCATE,
>> APR_OS_DEFAULT, pool));
>>
>> out_stream = svn_stream_from_aprfile2(file, TRUE, pool);
>>
>> SVN_ERR(svn_stream_printf(out_stream, pool, "%s %s\n", node_id, copy_id));
>>
>> SVN_ERR(svn_stream_close(out_stream));
>> return svn_io_file_close(file, pool);
>> }
>>
>> Is there any reason we don't switch to our standard pattern: write to a
>> temp file and rename? That would give us Subversion's standard retry
>> loop -- would that fix "requested operation cannot be performed"?
>
> fs_fs.c:move_into_file() already does the rename loop, so no objection.
> (assuming we document that the use of move_into_file() is for
> performance and virus scanners rather than for concurrent reader
> correctness)
>
I replaced svn_io_file_open, svn_stream_printf and svn_stream_close
with svn_io_write_unique and move_into_place (see attached patch).
Although this works correctly it shows bad performance. Loading a dump
from a little repo which mainly has a 2000 files commit now takes
about 400s while with the original version it only took about 100s.
Re: Problems with transaction file "next-ids" on Windows
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Wed, Jul 20, 2011 at 15:12:51 +0100:
> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>
> > Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
> >>
> >> each time when I am loading a certain dump file on Windows which
> >> contains one revision with over 100K changed paths I get the error
> >> "Can't open file
> >> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
> >> requested operation cannot be performed on a file with a user-mapped
> >> section open.". After looking at the mailing list archives and other
> >> mailing lists I found out that I am not the only one to encounter
> >> this problem and that in most cases a virus scanner was the cause of
> >> the problem. And indeed, adding next-ids to the exclusion list
> >> solved the problem.
> >>
> >> But now I wonder if svnadmin couldn't handle this case a bit more
> >> elegantly. IMHO it would make sense not to quit the load immediately
> >> but to try it again maybe after waiting half a second or so if this
> >> specific error occurs (some other users reported that they got the
> >> error "The process cannot access the file because it is being used
> >> by another process."). If we can't access next-ids after trying it
> >> let's say 5 times with a little pause after each try we still can
> >> quit the load process.
> >
> > It would be good to solve this now as that is one of the concerns with
> > the (partially implemented) design for revprop packing, due for release
> > in 1.8.
>
> The current implementation writes the file inplace:
>
> static svn_error_t *
> write_next_ids(svn_fs_t *fs,
> const char *txn_id,
> const char *node_id,
> const char *copy_id,
> apr_pool_t *pool)
> {
> apr_file_t *file;
> svn_stream_t *out_stream;
>
> SVN_ERR(svn_io_file_open(&file, path_txn_next_ids(fs, txn_id, pool),
> APR_WRITE | APR_TRUNCATE,
> APR_OS_DEFAULT, pool));
>
> out_stream = svn_stream_from_aprfile2(file, TRUE, pool);
>
> SVN_ERR(svn_stream_printf(out_stream, pool, "%s %s\n", node_id, copy_id));
>
> SVN_ERR(svn_stream_close(out_stream));
> return svn_io_file_close(file, pool);
> }
>
> Is there any reason we don't switch to our standard pattern: write to a
> temp file and rename? That would give us Subversion's standard retry
> loop -- would that fix "requested operation cannot be performed"?
fs_fs.c:move_into_file() already does the rename loop, so no objection.
(assuming we document that the use of move_into_file() is for
performance and virus scanners rather than for concurrent reader
correctness)
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Re: Problems with transaction file "next-ids" on Windows
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
>>
>> each time when I am loading a certain dump file on Windows which
>> contains one revision with over 100K changed paths I get the error
>> "Can't open file
>> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
>> requested operation cannot be performed on a file with a user-mapped
>> section open.". After looking at the mailing list archives and other
>> mailing lists I found out that I am not the only one to encounter
>> this problem and that in most cases a virus scanner was the cause of
>> the problem. And indeed, adding next-ids to the exclusion list
>> solved the problem.
>>
>> But now I wonder if svnadmin couldn't handle this case a bit more
>> elegantly. IMHO it would make sense not to quit the load immediately
>> but to try it again maybe after waiting half a second or so if this
>> specific error occurs (some other users reported that they got the
>> error "The process cannot access the file because it is being used
>> by another process."). If we can't access next-ids after trying it
>> let's say 5 times with a little pause after each try we still can
>> quit the load process.
>
> It would be good to solve this now as that is one of the concerns with
> the (partially implemented) design for revprop packing, due for release
> in 1.8.
The current implementation writes the file inplace:
static svn_error_t *
write_next_ids(svn_fs_t *fs,
const char *txn_id,
const char *node_id,
const char *copy_id,
apr_pool_t *pool)
{
apr_file_t *file;
svn_stream_t *out_stream;
SVN_ERR(svn_io_file_open(&file, path_txn_next_ids(fs, txn_id, pool),
APR_WRITE | APR_TRUNCATE,
APR_OS_DEFAULT, pool));
out_stream = svn_stream_from_aprfile2(file, TRUE, pool);
SVN_ERR(svn_stream_printf(out_stream, pool, "%s %s\n", node_id, copy_id));
SVN_ERR(svn_stream_close(out_stream));
return svn_io_file_close(file, pool);
}
Is there any reason we don't switch to our standard pattern: write to a
temp file and rename? That would give us Subversion's standard retry
loop -- would that fix "requested operation cannot be performed"?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems with transaction file "next-ids" on Windows
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mathias Weinert wrote on Wed, Jul 20, 2011 at 14:59:23 +0200:
> Hi,
>
> each time when I am loading a certain dump file on Windows which
> contains one revision with over 100K changed paths I get the error
> "Can't open file
> 'c:\Repositories\test\db\transactions\5445-479.txn\next-ids': The
> requested operation cannot be performed on a file with a user-mapped
> section open.". After looking at the mailing list archives and other
> mailing lists I found out that I am not the only one to encounter
> this problem and that in most cases a virus scanner was the cause of
> the problem. And indeed, adding next-ids to the exclusion list
> solved the problem.
>
> But now I wonder if svnadmin couldn't handle this case a bit more
> elegantly. IMHO it would make sense not to quit the load immediately
> but to try it again maybe after waiting half a second or so if this
> specific error occurs (some other users reported that they got the
> error "The process cannot access the file because it is being used
> by another process."). If we can't access next-ids after trying it
> let's say 5 times with a little pause after each try we still can
> quit the load process.
>
> What do you think about this idea?
>
It would be good to solve this now as that is one of the concerns with
the (partially implemented) design for revprop packing, due for release
in 1.8.
> Cheers,
> Mathias
>