BusyBox Bug and Patch Tracking
BusyBox
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000198 [BusyBox] Other minor always 03-30-05 05:13 11-03-05 19:20
Reporter farnerup View Status public  
Assigned To BusyBox
Priority normal Resolution won't fix  
Status closed   Product Version 1.00
Summary 0000198: cat does not check the return value of close(2)
Description cat (and possibly other programs) does not call close(2) explicitly on stdout, and thus doesn't check if it succeded or not. This is important for some device drivers and, I imagine, some filesystems.

# cp test /dev/foo && echo ok
cp: unable to close `/dev/foo': Input/output error
# cat test > /dev/foo && echo ok
ok
Additional Information
Attached Files

- Relationships

- Notes
(0000156)
vapier
04-15-05 22:05

this is really just Bug 107 ?
 
(0000623)
landley
10-14-05 18:40

Except that this doesn't tell you anything useful unless you call fsync() too, as has been mentioned repeatedly on linux-kernel.

http://seclists.org/lists/linux-kernel/2005/Sep/3103.html [^]

Media errors won't get reported if the data is still in cache, network errors won't be reported if it made it into the output buffer. So either you want to slow down cat with an fsync, or you want to make a pedantic change that doesn't actually mean anything. Which is it?

Rob
 
(0000624)
farnerup
10-17-05 00:25

Do what you wish, I wrote a device driver that reported the error status with the flush call and I though it was weird that the behaviour was different for cp and cat.
 
(0000657)
landley
11-03-05 19:20

Your driver is stupidly written.

The write() didn't fail, so the data was either cached or accepted by the device. Since we never did an fsync() to make sure that the data made it anywhere (to disk, through the named pipe to be read by another process, out the network interface, etc), if it was cached it almost certainly still is, so checking close still gives us absolutely no guarantees of anything at all. The write probably hasn't even been _scheduled_ yet, it's a completely false sense of security.

As recently as 2002, the linux kernel didn't even bother to pass on errors a device _did_ report on close, and the general consensus about fixing it was "why bother"?
http://lwn.net/2002/0328/kernel.php3 [^]

Linus Torvalds' opinion is that fsync() is the only thing that provides you with any sort of guarantee:
http://lkml.org/lkml/2005/9/11/49 [^]

Do you want us to add fsync() to cat?

I'll make a note of this, but it really isn't a bug.
 

- Issue History
Date Modified Username Field Change
03-30-05 05:13 farnerup New Issue
04-15-05 22:05 vapier Note Added: 0000156
10-14-05 18:40 landley Note Added: 0000623
10-14-05 18:41 landley Status assigned => feedback
10-17-05 00:25 farnerup Note Added: 0000624
11-03-05 19:20 landley Note Added: 0000657
11-03-05 19:20 landley Status feedback => closed
11-03-05 19:20 landley Resolution open => won't fix


Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker