From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
Description of problem:
lockf returns EINVAL if the third argument of the function lockf, len, is
negative, if running a kernel < 2.4.21 (currently, I'm using redhat
All the versions of the Single Unix Specification says that, when len is
negative, lockf must affect "the preceding bytes up to but not including the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Call lockf with a negative len argument
Actual Results: lockf return -1, errno==EINVAL.
Expected Results: lockf must return 0.
The glibc version is glibc-2.2.4-26.
glibc lockf just calls fcntl in the kernel.
if we change this, we change behavior to userspace, which is something we don't
want within a stable product release.
It isn't needed to change the kernel. You can call traslate the negative length
in lockf to a negative start and a positive length to fcntl, for example:
struct flock flock;
/* ... */
if (len < 0)
flock.l_start = len
flock.l_len = -len;
flock.l_start = 0;
flock.l_len = len;
RHEL2.1 is currently accepting only critical security fixes. This issue is
outside the current scope of support.