Ben LaHaise wrote:
>
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> > filesystems.
> >
> > Ideas, anyone?
>
> Don't use filesystems that require 64 bit inode numbers until all
> applications are using LFS. Personally I'd rather LFS not be an option
> anymore for applicaitons programs because of this compatibility
> issue. We've always known when starting down the LFS path that this day
> would come, and any filesystem that makes use of the upper 32 bits of
> ino_t had better issue a warning (none in the kernel proper *currently*
> do).
If so, we'd be better off completely deprecating the old calls and make
the LFS calls the default calls (and off_t == off64_t, ino_t == ino64_t,
etc.)
Sorry for being picky, but LFS, specifically, means using an heterogenous
API using seek64() instead of lseek() and so on and so forth. glibc 2.1
has a define option (__USE_FILE_OFFSET64) which enables this by default;
perhaps the right thing to do is to have this be the default, and have a
__USE_FILE_OFFSET32 as the backwards compatibility option instead.
-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]
