[Box Backup] inode, fsid, and OS dependencies
Tue, 14 Dec 2004 11:44:13 -0500
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.