[Box Backup] inode, fsid, and OS dependencies

[Joe Krahn]

While looking into info about inodes and filesystem IDs, I found some 
compatibility issues, even for POSIX systems. It also made me think 
about OS dependencies in general. So, here's some info/ideas:

When native Win32 support is merged, OS dependency issues will increase. 
If it were me, I would try to keep the code clean by consolidating 
OS-dependent code. So, instead of #ifdef WIN32/LINUX/etc., you just make 
a set of generic functions, then include source files for these 
depending on the OS, such as BoxWindows.cpp, BoxPosix.cpp, etc.

If it were me, I would use plain C for the OS functions. An alternative 
C++ approach would be an OperatingSystem class. It might be nice to have 
a POSIX class, then make subclass variants for BSD/Linux/etc.

As for filesystem ID (fsid) and inodes, the purpose, I think, is to use 
(fsid,inode) as a globally unique file identifier that does not change 
when renamed. Technically, struct statfs.f_fsid is the unique filesystem 
ID, but this field is not well supported. Struct stat.st_dev is well 
supported, but could change if a disk is added or removed. So, the 
mountpoint is a reasonable compromise. But, I would put this in the 
"OS-dependent" category. It may be better to use a filesystem label or 
GUID/UUID instead, depending on the OS.

Inodes are a further problem: Windows doesn't support inodes. (Maybe the 
Longhorn FS will.) It also turns out that inode is not always unique in 
   a POSIX system: some file systems have a larger actual inode number, 
and only return a hash of the real inode in stat.st_dev (i.e. Coda uses 
128 bit inodes). So, inode is also an OS dependent thing.

It might be good to have the inode field variable sized. Is that the 
case now? I haven't looked at the way data is stored on the server end.

Joe Krahn