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

Re: [bug] vtable=0x00000000 for the new FSFS when doing simultaneous commits

From: C.A.T.Magic <c.a.t.magic_at_gmx.at>
Date: 2004-05-09 07:56:20 CEST

C.A.T.Magic wrote:

> you create a unique filename through apr, but then DELETE
> that unique file. and then you try to create a new folder
> with the 'deleted' file's name. but since you delete the
> unique file first, the name is no longer unique and the
> second process is taking the same name.....

i tried it the quick way by deleting
   /* SVN_ERR (svn_io_file_close (txn_file, pool)); */
from svn_fs_fs__create_txn,
and this fixes the txn collisions.
(the file gets closed anyway, because of the pool).
but for some strange reasons i still get

svn: Unable to create new transaction.

which means that apr_file_mktemp is failing -
maybe a bug in apr for win32?

a better solution for Win32 meantime could be

   UINT GetTempFileName(
     LPCTSTR lpPathName,
     LPCTSTR lpPrefixString,
     UINT uUnique,
     LPTSTR lpTempFileName

it seems to me that the apr-function for tempfiles on win32
is pretty new:
   *) Fixed apr_file_mktemp on systems without mkstemp (Win32, etc).

(i'm using apr 0.9.5 dlls)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 9 07:56:30 2004

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.