Correct thanks for commit ff5e91840c92fbb3af70731ede8696114dfee7aa.

Thanks to Ben Kelly <btk@google.com> for tracking down the problem,
rather than Alexander Barton <alex@barton.de>.

Original message:

  Author: Rob Browning <rlb@defaultvalue.org>
  Date:   Tue Nov 5 17:17:45 2013 -0600

    Don't include atime when determining hardlink compatibility.

    Don't include the atimes since we're comparing two paths stat()ed at
    different times, and depending on the
    platform/filesystem/mount-options, that may result in two different
    atimes, even when the paths refer to the same file.

    Thanks to Alexander Barton <alex@barton.de> for tracking down the
    problem.

    Signed-off-by: Rob Browning <rlb@defaultvalue.org>
    Reviewed-by: Gabriel Filion <gabster@lelutin.ca>

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Treat stat fields correctly as signed, unsigned, or unspecified (cf. POSIX).

Patrick reported a problem with restore on Cygwin that was being
caused by bup's handling of unknown uid/gid values; it turns out that
Cygwin returns -1 in that situation:

  http://www.cygwin.com/cygwin-ug-net/ntsec.html
  "Special values of user and group ids"

However, bup didn't see -1; bup saw 4294967295, because it was
incorrectly converting some stat field values as unsigned when POSIX
says that they should be signed (or doesn't specify):

  http://pubs.opengroup.org/onlinepubs/009695299/basedefs/sys/types.h.html

To fix the problem, convert the stat fields correctly -- using the
widest type available (PY_LONG_LONG), and add a new common metadata
record (_rec_tag_common_v2) to store them correctly.  Test at runtime
for potential overflows that we can't rule out at compile time.

Store all of the fields (excepting the timestamp ns values, which we
already force to be non-negative) as signed vints because the overhead
should be negligible, and doing so means that we won't have to break
backward compatibility again if we ever decide we actually want to
store negative values.

Continue to read the legacy format as before, with the realization
that this may leave some existing archives broken.  At the moment, the
only known case is the Cygwin "unknown uid/gid" problem cited above,
and to help with that and similar cases, we'll be adding
--map-{user,group,uid,gid} options to restore.

Thanks to Patrick Rouleau <prouleau72@gmail.com> for the initial
report leading to the deeper problem.

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Reviewed-by: Gabriel Filion <gabster@lelutin.ca>
Add --map-user --map-group --map-uid and --map-gid options to restore.

Note that the usual metadata rules still appply, so a user or group
entry will normally take precedence over a uid/gid unless
--numeric-ids is specified.  So if you want to map a uid, for example,
you'll either need --numeric-ids, or you'll need to clear the
user/group like this:

  bup restore ... --map-user rlb= --map-uid 1000=2000

These options should also make it possible to recover from archives
that were broken as a result of our incorrect handling of
signed/unsigned stat values (recently fixed).

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Reviewed-by: Gabriel Filion <gabster@lelutin.ca>
bup-restore.md: add more detail to the restore --map-* documentation.

Thanks to Gabriel Filion <gabster@lelutin.ca> for the suggestions.

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Reviewed-by: Gabriel Filion <gabster@lelutin.ca>