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."
...of the superiority of Microsoft.
but they had more important things to do. At least until Balmer started throwing chairs.
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.
The first entry in a disk block, not the first entry in a directory. Each disk block is 512 bytes, so you can store around 30 files in there with shortish file names (each stores the name, the inode and a cumulative free space counter). For large directories you have around a one in 30 chance that the deleted file will be the first one in a block. Delete a dozen files from a large directory and there's a pretty large chance you'll hit this bug.
I am TheRaven on Soylent News
This bug has been around for a long time, but is only visible if you have large directories and delete files from them in between calls to readdir and seekdir. This is quite uncommon behaviour, and was incredibly uncommon 25 years ago when filesystems were much smaller and directories almost never contained enough files to require more than one or two disk blocks to store the directory.
When the Samba people found it, they decided to just code a work-around and not bother to report it to any of the BSD teams. If they had done, it would probably have been fixed in 22 years.
Now that it has been fixed in OpenBSD, the change can easily be taken and incorporated into FreeBSD, NetBSD, DragonFlyBSD and Darwin.
I am TheRaven on Soylent News
Except that the bug had been triggered many times before, seeing as how Samba had code in place to work around it.
Bug tracking software missed this because it's bug #1. lol.
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.
Yes, Samba did pass on what it found and it appears they were promptly shot down by someone on the *BSD side.
The Samba e-mail archives contain a message from over 3 years ago, but it doesn't give attribution to the *BSD source.
The Samba Bugzilla also has a bug reported more recently involving the same issue. Reading through the bug history, you can see there was one FreeBSD dev involved in the bug discussion, and he referenced a prior conversation between Tridge (Samba) and PHK (FreeBSD) where PHK said there was no bug in FreeBSD.
Am I the only one who thinks it's quite impressive to have 25 year old code still being used and employed on new systems?
What?
Samba could have reported it, but perhaps when they noticed in 2005, they also noticed that the July 2003 discussion on freebsd-hackers already acknowledged the existance of the bug, but never actually fixed it.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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
No, we did report it. The answer at the time was "this is allowed by POSIX, deal with it", can be seen in the bug report here :
:-). Eventually I just added a parameter that allowed our open directory cache to be turned off on *BSD. Once it got into the hands of Marc Balmer he took us seriously and fixed the bug.
https://bugzilla.samba.org/show_bug.cgi?id=4715
I did point out that no other POSIX system behaved like that, but that didn't seem to make much difference
Jeremy.
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.
That's "scarab" beetle, and don't call me Surly.