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

Re: WC corruption after checkout on Mac

From: Augie Fackler <durin42_at_gmail.com>
Date: 2007-11-14 16:26:49 CET

I've been running it for 25 minutes (flooring both cores) and I'm not
seeing any output. For what it's worth, I'm on 10.5.0, Core2Duo.
Do we think there's anything else I can try to nudge it into exposing
the bug? I *know* I've had this problem, I have had to redo a checkout
about once every 6 months (although, to be fair, that was 10.4.* or
prerelease 10.5 builds, so maybe the bug is fixed now).
Peace,
Augie

On Nov 14, 2007, at 9:35 AM, David Glasser wrote:

> Ben, Augie: can you try running Eric's program?
>
> --dave
>
> On 11/14/07, Augie Fackler <durin42@gmail.com> wrote:
>> And I've seen this bug once in a while and I don't even own Norton...
>>
>> On Nov 13, 2007, at 9:00 PM, Ben Collins-Sussman wrote:
>>
>>> Uh, I've had my Norton Autoprotect switched off since day 1.....
>>>
>>>
>>> On Nov 13, 2007 6:12 PM, Eric Gillespie <epg@google.com> wrote:
>>>>
>>>> Eric Gillespie <epg@google.com> writes:
>>>>
>>>>> Anyone with a Mac, please try this test program.
>>>>>
>>>>> - save it as bug.c
>>>>> - make bug
>>>>> - cp -r $svn_trunk/build data
>>>>> - while :; do rm -rf work; ./bug; done
>>>>>
>>>>> Let us know what happens. On one particular Mac we have, we get
>>>>> the random 0 byte files:
>>>>>
>>>>> work/gen_base.py 0 != 39113, unlink_error=2
>>>>> work/get-py-info.py 0 != 4255, unlink_error=2
>>>>> work/vc6-build.bat.in 0 != 5630, unlink_error=2
>>>>> work/gen_make.py 0 != 20457, unlink_error=2
>>>>> work/svn_config.vcproj.ezt 0 != 2515, unlink_error=2
>>>>> work/swig.m4 0 != 9023, unlink_error=2
>>>>> work/serf.dsp.ezt 0 != 2912, unlink_error=2
>>>>> ...
>>>>
>>>> Glasser is the man, as usual! He figured out that it is
>>>> triggered by having "Norton AutoProtect" running. I've filed a
>>>> bug with Apple, including everything necessary to reproduce.
>>>>
>>>> Now, what should *we* do about it? Maybe:
>>>>
>>>> - Add a FAQ entry
>>>> - Stop unlinking files we know don't exist
>>>> We know whether the rename failed or not; only unlink if so.
>>>> We should probably audit other del_on_pool_cleanup use, and,
>>>> for that matter, all unlink calls.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>>>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>
>
> --
> David Glasser | glasser_at_davidglasser.net | http://
> www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 14 16:27:07 2007

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.