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

Here's a quote I got about the subject:
"even without a virusscanner, you just can't assume that you're the only
component interested in a file. You "must" write your code with the
assumption that there will be a sharing violation when you try to open the
file. Indexing service, disk defragmenter, backup software, etc are all
possibilities."

Looks like the best approach would be to trap the error, and retry. (Given
this argument, I might argue that it belongs in APR too.)

On Thu, May 22, 2003 at 02:20:57PM -0600, D.J. Heap wrote:
> 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
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~