| Anonymous | Login | Signup for a new account | 11-10-2008 10:43 PST |
| Main | My View | View Issues | Change Log | Docs |
| 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 | |||||||||
|
|
|||||||||
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. |
| Copyright © 2000 - 2006 Mantis Group |