Repo corruption on Windows share: Opportunity Lock issue?

[Becker, Mischa J]

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Adrian Buehlmann
> Sent: Wednesday, May 02, 2012 4:18 PM
> To: Cowperthwaite, Michael
> Cc: mercurial at selenic.com
> Subject: Re: Repo corruption on Windows share: Opportunity Lock
> issue?
>
> On 2012-05-03 00:30, Cowperthwaite, Michael wrote:
> > That same post also mentions that Python's open() relies (relied?) on
> a broken (still?) MSVCRT open(). I have TortoiseHg's Overlay Icon
> Server running; does that use the Mercurial posixfile or the generic
> open() when it's scanning for file changes?
>
> TortoiseHgOverlayServer.exe was built on top of Mercurial (it contains
> it, together with Python), so yes, it uses Mercurial's posixfile. In fact, its
> sole job is to update the .hg/dirstate and .hg/thgstatus files, which are
> read by the TortoiseHg's shellextension (which by itself is doing only
> stat calls on working dir files). So there is nothing evil going on in the
> overlay stuff there.
>
> MSVCRT's open() is unlikely to ever change, as we have no influence
> on what CRT the Python project is shipping. But in theory, Microsoft
> licenses the sources of the CRT under some conditions that allow to
> tweak them, so that customers are able build their own, modified
> version of the CRT and ship a modified CRT with their applications. But
> the license forbids to publish the orginial and thus the modified
> sources.
>
> The problem you have might very likely be caused by Symantec's AV
> products. I wouldn't be surprised if they would open files without
> setting the FILE_SHARE_DELETE flag, or even worse, lock them into
> memory. If you are desperate enough, you might use Microsoft
> Sysinternal's Process Monitor and log the file system activity of the
> virus scanner process. If I recall correctly, it will show you the flags that
> are used on the CreateFile Windows API call (used for opening files). If
> the FILE_SHARE_DELETE flag is not set, then you are in trouble.
>

Ditto for your problem probably being caused by Symantec. I only ever had problems with repo corruption on my local C:\ drive where Symantec Endpoint Protection is turned on and I'm not allowed to tell it to ignore my repos.  In my case, I had to move all of my local repositories out to a network drive that has no antivirus running on it. I haven't had any corruption problems since.

Mischa

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.