> -----Original Message-----
> From: Gilles CHAUVIN
> Sent: Wednesday, August 28, 2002 9:07 AM
>
> Not as excellent as I wish it should be (I'm pretty sure this sentence
> doesn't mean anything ;)
Hey, it makes sense to me! (Of course, I did grow up in South
Louisiana...)
> > It does appear that squidGuard has tried to open <domains.diffq`>.
> > ==> We never tell SG which directories contain .diff files and which
> > ones do not contain .diff files.
> > ==> SG never complains about the directories that do not contain
> > .diff files.
> > ==> At some point prior to this error, SG looked for
> > /hacking/domains.diff and saw that it existed, and then began the
> > update process (which produced the error).
> >
> We both understand this the same way... ;)
We're off to a good start! ;-)
> > ==> If the problem was indeed that len(".diff\0")=6 (and not 5), *all*
> > of the .diff updates would have failed, not just one or two, right?
> >
> > Based on my comments above, I don't think what you changed
> > eliminated the problem; I think you may have masked the problem.
> >
> You're probably right about this point. It would be really great to have
> someone (who knows C programming) inspect that part of the code and tell
> us what he think about it. My reasoning (maybe totally wrong) was the
> following:
>
> Suppose the file name is "domains". Then, the function strlen(file),
> should return "7". Now you add space for the 5 chars extension,
> strlen(file)+5. So, somewhere in the computer memory are allocated 7+5
> bytes for storing "domains.diff" inside. Reading the "strcpy" man page
> tells it also copy the ending "NUL" character. I then thought it should
> be 7+6 and not 7+5 (because the ending \0 should be present in the the
> string too).
I like your logic, but it does seem to have a fatal flaw: No matter
what the filename is, (len("filename")+5) will *always* be less than
(len("filename")+".diff\0"). If this was the source of the problem,
*everybody's* .diff updates would fail. *All* of them.
The preceding paragraph is the real problem, but I also wonder...
Let's say you plug a 13 byte variable (domains.diff\0) into a 12 byte
slot. Later, you retrieve the variable (from pointer, length). Wouldn't
the result be 12 bytes long, not 14 ("domains.diff'%")?
[deleted database version info]
> Maybe you're right. But I still continue to think that's not a bug
> related to the database (because, it can't open the file xxx.diff). I
> think opening a file and doing things in the database are two different
> operations. In that case, it stops because it cannot find the file (the
> database shouldn't be open at this moment).
Concerning "... not related to the database..." - It could also be
related to the database functionality provided through the API.
All of the "Db->" statements in the code utilize functionality
within the Berkeley Db. There were quite a few changes in version
3.3.1.1 over 3.2.9 (see <http://www.sleepycat.com/update/3.3.11/if.3.3.11.html>)
and at least one bug was introduced in 3.3.1.1 and later fixed in 4.0.
> As both of us doesn't know C code, I hope someone could inspect that
> small part of squidGuard's source code and see what I've done good/wrong
> when modifying this.
I'd also be interested in knowing how it works for the other 99% of us
without making any changes. I'm not sure that "12<13" is C-specific.
> I really cannot explain more about this (and why it works when I change
> theses values). But, what I know is that it is working now (it wasn't
> before I modify the code).
You aren't getting the errors any more, but have you tested to make
sure the changes are actually made in the .db? A +domain *is* being
blocked after the update?
Just remember, if this stuff was easy, *anybody* could do it. ;-)
Rick
