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