Repo corrupted again, no idea why

[Dan Villiom Podlaski Christiansen]

On 2 Oct 2010, at 12:31, Christian Ebert wrote:

> * Adrian Buehlmann on Friday, October 01, 2010 at 22:37:52 +0200
>> There error scenario for the hardlink problem mentioned is  
>> described at
>> http://mercurial.selenic.com/bts/issue761
>>
>> In that scenario, as I understand matters, there are no error  
>> messages
>> at the moment the problem starts happening. The corruption is silent.
>>
>> The problem is, if a 'hg clone' was done (without --pull option),  
>> then
>> the destination and the source repo share files inside .hg/store by
>> using hardlinks [1], if the filesystem provides the hardlinking  
>> feature
>> (NTFS does).
>>
>> Mercurial is designed to break such hardlinks inside .hg if a  
>> commit or
>> push is done to one of the clones. The prerequisite for this is, that
>> the Windows API mercurial is using should give a correct answer, if
>> mercurial is asking "how many hardlinks are on this file?".
>
> From a paranoid pov hg clone w/o pull is dangerous anyway, e.g.
> rm -P:
>
> $ hg init testrm
> $ cd testrm/
> $ echo foo > a
> $ hg ci -Amfoo a
> $ cd ..
> $ hg clone testrm testrm-hardlink
> updating to branch default
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> $ rm -rP testrm-hardlink/
> $ cd testrm
> $ hg log
> abort: requirement  
> '� 
> ����������������������'  
> not supported!
>
> c

Perhaps you should file a bug with your operating system vendor? I  
just checked on my Mac, and all of ‘rm -RP’, ‘rm -rP’ and  
secure erase using the Finder work as expected on hardlinked  
repositories.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20101002/4c21ae99/attachment.p7s>