Re: [patches] RFC: Export inode generations to the userland

[Andreas Dilger <adilger@turbolabs.com>]

On Feb 18, 2002  22:06 +0100, Maciej W. Rozycki wrote:
>  As you may know, there are serious problems with creating unique file
> handles in the userland NFS server.  They exist because the inode
> generation number, which allows to determine if an inode was deleted and
> recreated, is currently only available to the kernel -- it's by no means
> exported to user programs[1].

Well, I don't see what's so bad with EXT2_IOC_GETVERSION?  It's not like
many Linux filesystems have inode generation numbers in the first place.
It may even be that reiserfs does/would implement the EXT2_IOC_GETVERSION
ioctl also (they implemented EXT2_IOC_GETATTR compatible with ext2/ext3).
You can wrap this inside glibc if you really want to, and that has the
added benefit of working with all kernels in existence.  That's not to
say this ioctl is the best interface...

> 1. Linux was modified to add another member of "struct stat" and "struct
> stat64".  The member provides the value of the inode generation at the
> time one of the stat syscalls is invoked.  It is named "st_gen" as it is
> the name other systems give it (it seems DEC OSF/1 and IBM AIX define this
> member currently).  New syscalls have been defined wherever spare space
> was not available in "struct stat" or "struct stat64", otherwise only the
> semantics of old ones was extended.

IIRC, there are several other desirable changes to struct stat/stat64
(64-bit timestamps, 32-bit UIDs/GIDs, and others I believe, some searching
should show up complaintants) so if there is really a need to add yet
_another_ stat struct/syscall we may as well do it right _this_ time
(like we've said every other time we change this interface).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/