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 kernel-2.4.9-e.3) 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 current offset". Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Call lockf with a negative len argument 2. 3. Actual Results: lockf return -1, errno==EINVAL. Expected Results: lockf must return 0. Additional info:
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; } else { 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.