After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 161634 - Possible typo in nautilus-burn-recorder.c
Possible typo in nautilus-burn-recorder.c
Status: RESOLVED FIXED
Product: nautilus-cd-burner
Classification: Deprecated
Component: cd-burner
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus CD Burner Maintainers
Nautilus CD Burner Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-12-18 16:23 UTC by Nicholas Skehin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch to change stdout_pipe to stderr_pipe (653 bytes, patch)
2004-12-18 16:35 UTC, Nicholas Skehin 		none Details | Review

Description Nicholas Skehin 2004-12-18 16:23:20 UTC 
On lines 956 and 957 of nautilus-burn-recorder.c, there are two fcntl calls:

fcntl (stdout_pipe, F_SETFL, O_NONBLOCK);
fcntl (stdout_pipe, F_SETFL, O_NONBLOCK);

I may be wrong, but from what I can see the second fcntl call will do nothing.
Given the function it appears in, I think the author probably meant:


fcntl (stdout_pipe, F_SETFL, O_NONBLOCK);
fcntl (stderr_pipe, F_SETFL, O_NONBLOCK);
Comment 1 Nicholas Skehin 2004-12-18 16:35:25 UTC 
Created attachment 34976 [details] [review]
Patch to change stdout_pipe to stderr_pipe
Comment 2 Bastien Nocera 2004-12-18 16:39:00 UTC 
Was already fixed in:

2003-09-02  Bastien Nocera  <hadess@hadess.net>

        * cd-recorder.c: (cd_recorder_write_iso_cdrecord): don't set
        non-blocking mode on stdout twice, but set it on stderr

I wonder how the bug was there for growisofs as well...

2004-12-18  Bastien Nocera  <hadess@hadess.net>

        * nautilus-burn-recorder.c:
        (nautilus_burn_recorder_write_growisofs): don't set
        non-blocking mode on stdout twice, but set it on stderr, patch
        by Nicholas J. Skehin <nicholas@skehin.com> (Closes: #161634)