You'd truncate the inode number. What's the big deal? Inode numbers aren't
that important - they're just about the _least_ important part of the data
returned for a readdir.
Sure, truncating the inode number may confuse some programs like old-style
/bin/pwd, but the thing is, we effectively _already_ do that by generating
essentially random numbers for filesystems that don't have UNIX-style
inode numbers anyway, so what's the big deal really?
The thing is, the "probably" is likely "probably not". There's a lot of
things that work quite well. Sure, if you lseek() you get confused. If
you do "stat()" and then mmap(), you'll get confused. But a lot of
programs really do just read/write. Or use llseek(), in fact. O_LARGEFILE
is actually a later thing tan llseek() was.
So the problem with EOVERFLOW is that it says that programs shouldn't do
anything at all because they _may_ do bad things.
And don't get me wrong - I think EOVERFLOW was (and is) actually a good
thing for the _transition_ period. Exactly because it breaks programs in
obvious ways, and early. It's good to be annoying in order to find
problems early and fix them.
But I also think that we're not in a transition period any more, and as a
result the annoyance part is just annoying an doesn't help find and fix
problems any more, it just makes legacy binaries not work even if they
could otherwise work fine (and _maybe_ have problems).
So something that made sense five years ago may not make sense any more,
is what I'm saying. These days, if somebody runs legacy binaries, they do
it because of archeology reasons or similar..
Linus
--
