Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 174043 - netatalk/papd fails to close pipe correctly
netatalk/papd fails to close pipe correctly
Product: Fedora
Classification: Fedora
Component: netatalk (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Depends On:
  Show dependency treegraph
Reported: 2005-11-23 19:25 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-30 12:37:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Corrects fclose on pipe (449 bytes, patch)
2005-11-23 19:26 EST, JW
no flags Details | Diff

  None (edit)
Description JW 2005-11-23 19:25:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217

Description of problem:
The papd application fails to correctly close pipe.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.read source file papd/lp.c

Actual Results:  See that fclose is always invoked, even if it is a pipe.

Expected Results:  Should be possibly using pclose.

Additional info:

From pclose manual entry:

       "The return value from popen() is a normal standard I/O  stream  in  all
       respects  save  that  it  must  be  closed  with  pclose()  rather than
Comment 1 JW 2005-11-23 19:26:08 EST
Created attachment 121427 [details]
Corrects fclose on pipe
Comment 2 Jason Vas Dias 2005-11-30 12:37:02 EST
I'm not sure this is a good idea.

Closing the stream unconditionally with fclose() means that the reader process
will get a broken pipe error, ie. it knows that papd is finished with it.

pclose() on the other hand "waits for the associated process to terminate" 
(man popen(3)) before closing the stream and returns the process exit status .
Perhaps lp programs could depend on the broken pipe error to know when input
is finished; if papd used pclose, it could wait forever for the reader to 

There is no value in using pclose() rather than fclose() if you do not want to
wait for the program at the other end of the pipe to terminate.

Does this use of pclose fix any definite, reproducible problem ? If so, please
re-open this bug with details of how to reproduce, and I'll contact the upstream
maintainers to get their opinion on this issue. 
Comment 3 JW 2005-11-30 19:04:26 EST
(In reply to comment #2)
> I'm not sure this is a good idea.

That is an interesting conclusion. And an interesting discusssion about why
pclose() might not be a good idea.

Now, let's have a look at the glibc code for pclose:

    int __new_pclose (FILE *fp)
       return _IO_new_fclose (fp);

Do you see what I can see?

Note You need to log in before you can comment on or make changes to this bug.