Allowing apr_file_trunc() to "fail" with APR_ESPIPE fixes all issues and passes all tests... committed.
On Jan 25, 2014, at 12:37 PM, Jim Jagielski <[email protected]> wrote: > As can be seen, I'm trying to do some work on shm; in > case we keep using ftok(...,1) for SysV, I want to make > posix shm a viable alternative, but I'm running into > some issues. > > One semi-immediate on is that we do the following: > > tmpfd = shm_open(shm_name, O_RDWR | O_CREAT | O_EXCL, 0644); > ... > status = apr_os_file_put(&file, &tmpfd, > ... > status = apr_file_trunc(file, new_m->realsize); > > And the apr_file_trunc fails for me with an Illegal > seek. In apr_file_trunc we do: > > if (ftruncate(fp->filedes, offset) == -1) { > return errno; > } > return apr_file_seek(fp, APR_SET, &offset); > > and apr_file_seek() does a lseek(). And that's where > the problem is because lseek() returns -1 with ESPIPE. > > That seems like a valid error in this case, which begs > the following questions: > > 1. Why are we doing the apr_file_trunc() in shm? > 2. Assuming it's required, why do we expect the lseek > on it to succeed? > 3. Assuming the failure is NOT expected, or is system > dependent, how should apr_file_seek handle it? > >
