Geoff Keating wrote:
>
> > Date: Mon, 30 Oct 2000 11:29:09 -0800
> > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
>
> > I believe I wrote this back as well: this will affect *ALL* applications,
> > even those that don't need large file support. This change really needs
> > to happen, or any non-LFS application is DANGEROUS AND UNUSABLE.
>
> If this is the case, then we have a real problem. We can't change the
> size of ino_t in applications linked to earlier versions of glibc;
> they will always have a 32-bit ino_t. So such programs will be around
> for possibly quite a long time and we need to deal with them.
>
> I believe the correct thing to do in such cases is to do the same
> thing for files whose ino_t doesn't fit in 32 bits as to those whose
> off_t doesn't fit in 32 bits: return errors whenever stat() is called
> on such files.
>
Yes, of course. However, some filesystems will have large inode numbers
for all, or nearly all, files.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
