Re: [rdiff-backup-users] inodes and Windows

[Andrew Ferguson]

On Apr 14, 2008, at 7:08 PM, Josh Nisly wrote:

> 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.


Josh,

I think inode 0 is a valid inode number (all I can tell so far is that  
it needs to be unsigned). Zero is probably the number of some  
physically very early inode that no one would every backup, but even  
so, we should play it safe.

I like the idea of using -1 to indicate that the underlying FS did not  
return a valid inode number. We can take advantage of the fact that  
stat(2) returns a non-negative value, but cmodule.c turns that into a  
PyInt or PyLong, both of which can accept negative values.

Now that I think about it, there's probably a bug in cmodule.c for the  
stat stuff. Instead of PyInt_FromLong() it should be  
PyLong_FromUnsignedLong() since technically ino_t is an unsigned long  
(at least on Linux and Mac OS X). The downside to fixing this bug is  
that using PyLong's (represented as bignum's internally, I believe)  
instead of PyInt's (represented as longs internally) is a performance  
hit, although I don't know how bad.


Andrew