[Box Backup] inode, fsid, and OS dependencies

[Joe Krahn]

Nick Knight wrote:
> 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.
OK; Does it stay the same on a rename, to allow for the renamed-file 
tracking? And (for my own info) how do you access this number?

I suppose Win32 should put this in the stat inode field, but Win32 isn't 
very ANSI/POSIX friendly.

Joe

> 
> -----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 
> 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
> _______________________________________________
> boxbackup mailing list
> boxbackup@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> 
> 
> _______________________________________________
> boxbackup mailing list
> boxbackup@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup