Bug 174043 - netatalk/papd fails to close pipe correctly
Summary: netatalk/papd fails to close pipe correctly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: netatalk
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-24 00:25 UTC by JW
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-11-30 17:37:02 UTC
Type: ---
Embargoed:


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

Description JW 2005-11-24 00:25:24 UTC
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):
netatalk-2.0.2-3

How reproducible:
Always

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

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
       fclose()"

Comment 1 JW 2005-11-24 00:26:08 UTC
Created attachment 121427 [details]
Corrects fclose on pipe

Comment 2 Jason Vas Dias 2005-11-30 17:37:02 UTC
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 
terminate.

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-12-01 00:04:26 UTC
(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.