[darcs-users] Re: [BK] upgrade will be needed

Ralph Corderoy ralph at inputplus.co.uk
Thu Feb 24 18:39:29 UTC 2005


Hi David,

> Attached are the results on the darcs repository from three runs:

Thanks, I'm working through them.

One odd, at least to me, thing is the repeated appearance of the same
repository file mapped into different areas and with different inode
numbers.  For instance

    $ g SlurpDirectory get.195    # One particular maps sample.
    b64f1000-b64f7000 r--s 00000000 03:01 834406     /tmp/foo/SlurpDirectory.lhs
    b6644000-b664a000 r--s 00000000 03:01 834575     /tmp/foo/SlurpDirectory.lhs
    b665c000-b6662000 r--s 00000000 03:01 834574     /tmp/foo/SlurpDirectory.lhs
    b6662000-b6669000 r--s 00000000 03:01 834573     /tmp/foo/SlurpDirectory.lhs
    b6669000-b6670000 r--s 00000000 03:01 834570     /tmp/foo/SlurpDirectory.lhs
    b6670000-b6677000 r--s 00000000 03:01 834569     /tmp/foo/SlurpDirectory.lhs
    b6677000-b667e000 r--s 00000000 03:01 834565     /tmp/foo/SlurpDirectory.lhs
    b667e000-b6685000 r--s 00000000 03:01 834543     /tmp/foo/SlurpDirectory.lhs
    b6685000-b668c000 r--s 00000000 03:01 834539     /tmp/foo/SlurpDirectory.lhs
    $ 

Columns are start and end of address space, flags (read, write, execute,
shared or private), offset within file -- so 0 is fine, major:minor
device number, inode number, one possible pathname for that inode.

Is this reasonable, i.e. can you think why there would be multiple
hard-linked copies of SlurpDirectory.lhs in existence towards the end of
the `darcs get' and that they'd be mapped in under different pathnames?

Cheers,


Ralph.





More information about the darcs-users mailing list