Slashdot Mirror
The 25-Year-Old BSD Bug
sproketboy writes with news that a developer named Marc Balmer has recently fixed a bug in a bit of BSD code which is roughly 25 years old. In addition to the OSnews summary, you can read Balmer's comments and a technical description of the bug.
"This code will not work as expected when seeking to the second entry of a block where the first has been deleted: seekdir() calls readdir() which happily skips the first entry (it has inode set to zero), and advance to the second entry. When the user now calls readdir() to read the directory entry to which he just seekdir()ed, he does not get the second entry but the third. Much to my surprise I not only found this problem in all other BSDs or BSD derived systems like Mac OS X, but also in very old BSD versions. I first checked 4.4BSD Lite 2, and Otto confirmed it is also in 4.2BSD. The bug has been around for roughly 25 years or more."
How many "eyes" were watching BSD systems use Samba for a DOS filesystem? Seems to me, someone saw behavior and exactly because it was open source, looked into it, found the coding error and filed a bug report. It will be fixed, because everyone now knows about this, and that too is a side effect of open source, even if it's related to the politics.
Erm. That's not what "many eyes make bugs shallow" means.
Well. Just reading the source is part of it, but not all.
Fact is, if I run into odd behaviour when testing/using - if the source is available I can read it, I can breakpoint.
I cannot do that with a binary.
So yes. Things did occur as they were supposed to. Someone found something odd, they were able to look at code in question, and fix it.
The shallowness is the fact that there is a direct connection between the thousands of testers/users and the code in question.
Instant turnaround. No "user reports behaviour in detailed fashion, including testcase, to some corporate e-mail address, and maybe it eventually gets a to a developer three layers down who may be able to figure it out and fix it if he has the time"
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
Considering how old this bug is, and how much work-around code probably exists as a result, I wonder how many new bugs this bug fix will create.
Wuh? thousands of projects that prove the point, and one single bug that doesn't, so reject the whole argument?
You sound like those people that don't like evolution. The concept of shallow bugs is an approximate description of how things work, not a methodology. Also, if enough people stare at the code and use it, they will find the bugs that matter.
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
You think this only happens in the open source world? Let me show you what the "defect priority analysis" would look like at my work were we to receive a report about this bug: Reproducible: Yes Frequency of occurrence: Extremely low, only comes manifests for a very rare corner case. Systems known to be impacted: None, systems that have noticed defect previously have already implemented a workaround. Current known impact upon the functionality of the system: None Systems currently using code where defect is present with no impact: All systems accessing a directory Potential negative impact of an incorrect fix: Extremely high, potentially crippling filesystem traversal. Proposed solution: Wait till people stop using DOS filesystems.