[rdiff-backup-users] inodes and Windows

[Josh Nisly]

rdiff-backup has a check when renaming a file to prevent it from 
renaming over the same inode (rpath.py, around line 247). I started 
porting this check directly to windows, but the more I think about it, 
the less I'm sure that it's a good idea. On Windows, NTFS theoretically 
supports hardlinks (Microsoft had to implement it to claim posix 
compliance), but in practicality it doesn't exist, and isn't supported 
well, even by Microsoft's own programs. I've never seen a Windows 
program that even attempts to handle hardlinks, so I'm not sure it's 
worth trying to handle them in rdiff-backup.

There are implementations available that attempt to generate inode 
numbers based on various attributes, but the inode numbers may shift in 
certain circumstances. I believe that if Windows ever starts using 
hardlinks, Microsoft will be forced to implement a better API for them, 
and when they do that, we can use it.

Because Windows has no concept of inode numbers, the stat function fills 
in 0 for all files. This obviously triggers the check for renaming over 
hardlinked files. Here is where I'm not sure what to do. Is 0 a valid 
inode number on unix? If not, we could just check for that. We could 
also fill in a known value (maybe -1) in cmodule.c. Yet another option 
would be to explicitly check os.name, but that could be slow if we're 
renaming a file on a remote connection.

Thoughts?
JoshN