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.
-- ** R.E.Wolff@BitWizard.nl ** 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:48 EST