What is the session.save_path set to? And on what kind
of partition does that exist? (never seen this before, might be something broken in your system..)

This occurs both when session.save_path is the default 
(/tmp) and when I set it to something else.  The 
session files are created successfully.  Like I said in 
the original submissions, the sessions appear to work 
just fine, and the warning only happens when starting a 
fresh session.  It's totally possible that something is 
broken on the system, but that would seem to be at odds 
with the apparent functionality despite the warning.

Can you reproduce this within some other machine?
And are you sure it's not just some bug in that kernel?
(latest is 2.2.25 already.. :)

I certainly hope that I can't reproduce this bug, since 
all it takes is a call to session_start()--all configs 
are out-of-the-box defaults.  No, I am not sure it's 
not a kernel bug, but the same scripts work flawlessly 
on my FreeBSD box.  I guess I will keep it as 
@session_start() and see if the admin will upgrade the 
kernel (and the Apache installation).

Since even you can't reproduce it on another box, we should
assume it's just problem with the system, not PHP.

ok, i also had this bug with 4.3.2 on a RH 6.2 system and could reproduce it.

the php source code for this shows in 4.2.2:
-------------------------------------
if (n != sbuf.st_size) {
        efree(*val);
        return FAILURE;
    }
-------------------------------------

while in 4.3.2:
-------------------------------------
if (n != sbuf.st_size) {
        if (n == -1)
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "read failed: %s (%d)", strerror(errno), errno);        
        else
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "read returned less bytes than requested");

        efree(*val);
        return FAILURE;
    }
-------------------------------------
so basically its the same code as in 4.2.2 just with
some warning-messages added.

so i assume the reason for the warnings was also there in 4.2.2. but with 4.2.2 the whole stuff worked, so maybe that
warning should be safe to ignore.

i just commented the 2 warnings out in the source code, works for me now (altough not a clean solution;)

i think the whole stuff might be caused by some 32/64 bit troubles in the system. this is what i found somewhere else:

------------------------
At a glance I'd say an lstat limit. There's an lstat64() call whose returned structure has wider size fields. That's the core reason for this ugly open64/lseek64/... fiasco - binary compatability :-(
Given that system calls are a binary API you're pretty much stuck with this.
---------------------------