Re: [PATCH 0/2] Squashing long inodes.

[Denis Obrezkov <reprofy at etersoft dot ru>]

I understand that glibc has its own global purposes and its own view
on the problem. Let me introduce user's view.
First of all, I completely agree that programs should be compiled
with _FILE_OFFSET_BITS defined to 64. Also I believe that one day all
programs will use only proper structures for proper aims.
But unfortunately today isn't this day, probably tomorrow isn't too.
Thus we have some legacy programs which couldn't be recompiled at all
and programs which couldn't be recompiled with this flag due to their
nature(mixing 32bit and 64bit things will cause undefined behavior).
And these programs aren't work because hundreds of packages and 
libraries
use stat only to make sure themselves that needed file exists. They 
fail
every time when they want to checkout file's existence. I think it's
more serious bug than all the bugs which may be caused by squashing.
Also in this case(changing somehow inodes) we could take care of users
by outputting some kind of dmesg that squashing s used. So the question 
is:
could you tell me what is the better way - squash or zeroing?
Even if we wouldn't do something with inode in glibc, we, simple users,
have to make our programs work. For your impartiality could I remind 
you
that there are a lot of implementations of squashing inodes in the
kernel scope, e g fuse:

/*
 * ino_t is 32-bits on 32-bit arch. We have to squash the 64-bit value 
down
 * so that it will fit.
 */
static ino_t fuse_squash_ino(u64 ino64)
{
        ino_t ino = (ino_t) ino64;
        if (sizeof(ino_t) < sizeof(u64))
                ino ^= ino64 >> (sizeof(u64) - sizeof(ino_t)) * 8;
        return ino;
}


Moreover, in some programs if inode is zero, they think that file 
doesn't
exist, not the perfect way to use stat, doesn't it? So, zeroing inode 
is
precisely safer way, but it also has its own minuses.

And there is one thing that I can't understand. Linux kernel has its 
own
function, wrapper around stat64 for old systems, it's called 
cp_old_stat.
This function has behavior similar to glibc's __xstat32_conv but it 
also
outputs the warning message about old stat using. So why glibc doesn't 
use it?