+/* As long as it gets... */
+#define uint64 unsigned off_t
+#endif
+
+/* 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: In future, we should probable split the device number into
+ * major/minor, and transfer the two parts as 32-bit ints. That gives
+ * you somewhat more of a chance that they'll come from a big machine
+ * to a little one in a useful way.
+ *
+ * FIXME: Really we need an unsigned type, and we perhaps ought to
+ * cope with platforms on which this is an unsigned int or even a
+ * struct. Later.
+ */
+#define INO64_T uint64
+#define DEV64_T uint64