[Box Backup] inode, fsid, and OS dependencies

Nick Knight boxbackup@fluffy.co.uk
Wed, 15 Dec 2004 11:28:43 -0000

Speaking from the win32 port - I agree with all of that, win32 however
does support a file number, unique to that file on that file system.

-----Original Message-----
From: boxbackup-admin@fluffy.co.uk [mailto:boxbackup-admin@fluffy.co.uk]
On Behalf Of Joe Krahn
Sent: 14 December 2004 16:44
To: boxbackup@fluffy.co.uk
Subject: [Box Backup] inode, fsid, and OS dependencies

While looking into info about inodes and filesystem IDs, I found some=20
compatibility issues, even for POSIX systems. It also made me think=20
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=20
OS-dependent code. So, instead of #ifdef WIN32/LINUX/etc., you just make

a set of generic functions, then include source files for these=20
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=20
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=20
(fsid,inode) as a globally unique file identifier that does not change=20
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=20
supported, but could change if a disk is added or removed. So, the=20
mountpoint is a reasonable compromise. But, I would put this in the=20
"OS-dependent" category. It may be better to use a filesystem label or=20
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=20
   a POSIX system: some file systems have a larger actual inode number,=20
and only return a hash of the real inode in stat.st_dev (i.e. Coda uses=20
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=20
case now? I haven't looked at the way data is stored on the server end.

Joe Krahn
boxbackup mailing list