Re: glibc is the culprit - Re: vfs.txt and i_ino

[Rogier Wolff]

Guest section DW wrote:
> On Sun, Feb 10, 2002 at 11:58:48AM +0000, Anton Altaparmakov wrote:
> 
> > So glibc is for some reason hiding inode zero from us...
> 
> Well, we can read the source..
> For example, sysdeps/unix/readdir.c:
> 
> /* Read a directory entry from DIRP.  */
> DIRENT_TYPE *
> __READDIR (DIR *dirp) {
>       do {
>               ...
>               /* Skip deleted files.  */
>       } while(dp->d_ino == 0);
> 
>       return dp;
> }
> 
> Or, for example, sysdeps/generic/glob.c:
> 
> # define REAL_DIR_ENTRY(dp) (dp->d_ino != 0)
> 
> The glibc code assumes that a zero ino
> means a file that is to be skipped.
> 
> Many filesystem types use a zero d_ino to denote a deleted file.
> Of course user space should not worry about such things -
> the readdir system call should only return non-deleted items -
> but some systems leave this visible.
> (Also in the Linux kernel source one finds places where either
> ino is returned, or 0, in case no ino was found.)
> 
> It is probably best to avoid giving real files ino 0.

Problem is: It is NOT a real file. It's the '$MFT'. It is normally
hidden from userspace, but with a special option it becomes (partly,
as we've seen) visible.

Inode numbers make sense on NTFS, so it's a shame if you can't export
them "as is" to userspace.

Anton, How about a quick workaround: remap the $MFT inum to something
else. There are a couple of reserved inumbers in the 10-16 range,
right?

                        Roger. 

-- 
** address@hidden ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots.