[Box Backup] inode, fsid, and OS dependencies

[Nick Knight]

The file index is obtained by calling GetFileInformationByHandle and
combining the low and high part of the serial number.

For the Win32 version I have implemented the stat functions which
populate the inode fields.

MS describe the index as:

"Low-order part of a unique identifier associated with the file.=20
Note that this value is useful only while the file is open by at least
one process. If no processes have it open, the index may change the next
time the file is opened.=20

The identifier (low and high parts) and the volume serial number
uniquely identify a file on a single computer. To determine whether two
open handles represent the same file, combine this identifier and the
volume serial number for each file and compare them."

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

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=20
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

>=20
> -----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
>=20
> 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:
>=20
> When native Win32 support is merged, OS dependency issues will
increase.
>=20
> 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
>=20
> a set of generic functions, then include source files for these=20
> depending on the OS, such as BoxWindows.cpp, BoxPosix.cpp, etc.
>=20
> 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
>=20
> a POSIX class, then make subclass variants for BSD/Linux/etc.
>=20
> 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

> when renamed. Technically, struct statfs.f_fsid is the unique
filesystem
>=20
> 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

> GUID/UUID instead, depending on the OS.
>=20
> Inodes are a further problem: Windows doesn't support inodes. (Maybe
the
>=20
> 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.
>=20
> 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.
>=20
> Joe Krahn
> _______________________________________________
> boxbackup mailing list
> boxbackup@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
>=20
>=20
> _______________________________________________
> 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