Repo corrupted again, no idea why

Mads Kiilerich mads at kiilerich.com
Sat Oct 2 16:51:51 UTC 2010


  Adrian Buehlmann wrote, On 10/02/2010 01:56 PM:
> On 02.10.2010 12:31, Christian Ebert wrote:
>>  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!
> I didn't even know about this -P option of rm (what unix/linux was
> that?). Only found this for BSD:
>
> -P      Overwrite regular files before deleting them.  Files are over-
>          written three times, first with the byte pattern 0xff, then
>          0x00, and then 0xff again, before they are deleted.  Files with
>          multiple links will not be overwritten nor deleted unless -f is
>          specified, a warning is generated instead.

I think that Mercurials use of hardlink is a fine optimization, based on 
the assumptions that all users of the file don't modify the file without 
breaking the hardlink / creating their own copy. Making assumptions _is_ 
dangerous! Fortunately most programs and users knows not to edit file 
with multiple links, so it is a reasonable assumptions. Programs that 
don't know and use Mercurials locking mechanism will however be racy and 
slightly dangerous.

I think the paranoid should fear rm -rf /home more than -P.

However, AFAIK the usual file systems / device mappers makes no promise 
that they won't copy data around, so I don't see any point in using such 
a shredder option. For some file systems and device mappers it is a 
feature that removed and overwritten content remains available.

/Mads




More information about the Mercurial mailing list