RE: svn.collab.net is now running Subversion 0.23.

Yes, I definitely agree there is a bug somewhere...at this point I have
no idea where it is at, but I'm doubting more and more that it is really
in Windows. Brane, you were running on a ramdisk, right? Is it a MS
supported ramdisk driver?

For the stat64 calls -- I believe apr does the stat calls as part of the
setting-read-only-on-off, and I have included that piece of apr code in
the test program, so I think I've got those covered.

I have also run four of them in different directories simultaneously
trying to stress the file system and no luck so far.

The feedback I've gotten from MS (just on their
microsoft.public.win2000.file_system newsgroup) is that they strongly
believe it is a third party service or AV type utility (even inactive)
and that CloseHandle is definitely synchronous -- meaning the kernel and
file system do all work and remove sharing reservations before the call
returns.

So far I have been completely unable to reproduce this on any machine
but my multiprocessor one that has Sophos on it.

DJ

-----Original Message-----
From: Philip Martin [mailto:pm@localhost] On Behalf Of Philip Martin
Sent: Thursday, May 22, 2003 1:39 PM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.

"D.J. Heap" <djheap@dhiprovo.com> writes:

> By the way, I can reproduce this in seconds with my test program now,
> *if* I turn on Sophos AV realtime scanning. But I'm not sure it is
> really the same problem. It's possible Sophos is exaggerating a
Windows
> problem, or it could just be causing a different but similar problem,
so
> I'm trying to remove it from the equation.

If switching on "Sophos AV realtime scanning" causes a working program
to fail then that looks like a bug to me. As I have no idea what
"realtime scanning" involves I can't say whether it a bug in your
program, in Sophos, or in Windows.

> If anyone is interested I can provide the (fairly small and ugly) test
> program. It tries to mirror what I think is basically happening in
> Subversion:
>
> Create a temp file,
> update the temp file,
> close the temp file,
> turn read-only bit on for the temp file,
> turn off the read-only bit of the *real* file,
> rename the temp file onto the *real* file.
>
> Does this sequence look correct to the svn developers out there?

If I strace a commit (only bar1/foo1 modified) on Linux I see

open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
= 3
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
= 3
open("/home/pm/sw/subversion/obj/wcstress.1158/.svn/entries", O_RDONLY)
= 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/.svn/entries",
O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries",
O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar2/.svn/entries",
O_RDONLY) = 3
open("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/entri
es", O_WRONLY|O_CREAT, 0666) = 13
stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries
", {st_mode=S_IFREG|0444, st_size=781, ...}) = 0
chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries"
, 0666) = 0
rename("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/tmp/ent
ries",
"/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries") = 0
stat64("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries
", {st_mode=S_IFREG|0644, st_size=797, ...}) = 0
chmod("/home/pm/sw/subversion/obj/wcstress.1158/trunk/bar1/.svn/entries"
, 0444) = 0

so it looks like you are missing some stat calls.

> Of course, it doesn't recreate the problem yet without AV scanning
> going.

Perhaps you need to stress the filesystem, i.e. have a second
program/thread which is just opening, reading and/or writing, and then
closing a set of files.

-- 
Philip Martin
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org