-/* We want to manipulate 64-bit inums. On some systems
- * STRUCT_STAT.st_ino can be bigger than an ino_t depending on the
- * combination of largefile feature macros. Rather than try to guess,
- * we just internally store them in the largest know type. Hopefully
- * it's enough. */
-#define INO_T int64
+/* Starting from protocol version 26, we always use 64-bit
+ * ino_t and dev_t internally, even if this platform does not
+ * allow files to have 64-bit inums. That's because the
+ * receiver needs to find duplicate (dev,ino) tuples to detect
+ * hardlinks, and it might have files coming from a platform
+ * that has 64-bit inums.
+ *
+ * The only exception is if we're on a platform with no 64-bit type at
+ * all.
+ *
+ * Because we use read_longint() to get these off the wire, if you
+ * transfer devices or hardlinks with dev or inum > 2**32 to a machine
+ * with no 64-bit types then you will get an overflow error. Probably
+ * not many people have that combination of machines, and you can
+ * avoid it by not preserving hardlinks or not transferring device
+ * nodes. It's not clear that any other behaviour is better.
+ *
+ * Note that if you transfer devices from a 64-bit-devt machine (say,
+ * Solaris) to a 32-bit-devt machine (say, Linux-2.2/x86) then the
+ * device numbers will be truncated. But it's a kind of silly thing
+ * to do anyhow.
+ *
+ * FIXME: I don't think the code in flist.c has ever worked on a system
+ * where dev_t is a struct.
+ */
+
+struct idev {
+ uint64 inode;
+ uint64 dev;
+};