Red Hat Bugzilla – Bug 977872
fpathconf for a FIFO returns a different value than that for a directory
Last modified: 2016-11-24 07:12:01 EST
+++ This bug was initially created as a clone of Bug #916656 +++ Description of problem: this is a copy of F17 bug 879515. pathconf for a FIFO returns a different value than fpathconf. according to SUSv3, the result from fpathconf for a directory should be the same as for a FIFO in that directory. For more details see http://sourceware.org/bugzilla/show_bug.cgi?id=12723 https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3078 Version-Release number of selected component (if applicable): kernel-3.7.0-0.33.el7.x86_64 glibc-2.16-29.el7.x86_64 How reproducible: always Steps to Reproduce: 1. mkfifo fpathconf-t.15 2. mkfifo fpathconf-t.16 3. gcc fpathconf-t.c 4. ./a.out Actual results: On RHEL7 (and F17): test15 PASS - fpathconf for 'fpathconf-t.15' (65536) equals pathconf for 'fpathconf-t.15' (65536) test16 FAIL - fpathconf for '.' (4096) does not equal fpathconf for 'fpathconf-t.16' (65536) Expected results: On RHEL6: test15 PASS - fpathconf for 'fpathconf-t.15' (4096) equals pathconf for 'fpathconf-t.15' (4096) test16 PASS - fpathconf for '.' (4096) equals fpathconf for 'fpathconf-t.16' (4096) --- Additional comment from Karel Srot on 2013-03-01 03:01:41 EST --- There seems to be similar problem with pathconf. From LSB test suite: pathconf(".", _PC_PIPE_BUF) did not return same value as pathconf("pathconf-t.15", _PC_PIPE_BUF) expected: 65536, observed: 4096 --- Additional comment from Siddhesh Poyarekar on 2013-03-01 08:36:02 EST --- I've made another subtle change to the bz summary. The standard doesn't say that the fifo pipe buffer is the same size as its containing directory. What it says is that if the file/descriptor passed to {f}pathconf is a directory, then the buffer size returned could be for any FIFO that exists in it or could be created in it. The only sane value for this is the default value of pipe buf size for Linux, since the value is dynamic on Linux (and the default is different form PIPE_BUF). I've proposed a fix upstream: http://sourceware.org/ml/libc-alpha/2013-03/msg00009.html --- Additional comment from Siddhesh Poyarekar on 2013-03-08 07:46:53 EST --- This is what finally went upstream: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=adbb8027be47b3295367019b2f45863ea3d6c727 Code reverted to use PIPE_BUF since the linux pipe buffer size is not guaranteed to be the size of any atomic write and hence violates the spec. --- Additional comment from Karel Srot on 2013-03-27 03:51:52 EDT --- According to the latest comments from LSB bug this bug has to be fixed in distribution in order to be LSB compliant. https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3078#c18
glibc-2.17-11.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/glibc-2.17-11.fc19
Package glibc-2.17-11.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.17-11.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11737/glibc-2.17-11.fc19 then log in and leave karma (feedback).
glibc-2.17-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.