On Tue, 20 Mar 2001, David Harris wrote:
>
> Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
> > I think you'll still have problems with this technique, unless you
> > tie/untie every time. I'm looking at the perldoc for DB_File version
> > 1.76, at the section titled "Locking: the trouble with fd". At the very
> > least, you'd have to call sync after acquiring a write lock but before
> > writing anything.
>
> Here is more information from the original discovery of the bug. This
> contains the test cases that actually show the database corruption. Also
> some documentation on the details such as systraces that show reading
> happens before the flock system call.
>
> http://www.davideous.com/misc/dblockflaw-1.2.tar.gz
> http://www.davideous.com/misc/dblockflaw-1.2/
>
> Sync may or may not work, depending on how the low level buffering is
> implemented.
So basically what you are saying is that sync() is broken and shouldn't be
used at all. Something fishy is going on. The purpose of sync() is to
flush the modifications to the disk.
> If it re-reads all information from disk I don't think you have
> any advantage over simply closing the DB_File and opening it again.
Why should it re-read the file, when it's suppose to *write* it down to
the disk. That's the benefit of using dbm, is that only some blocks of the
file are read into a memory.
Unless you are talking about a process that wants to read after some other
process had changed the database, and there is a hazard that the former
process has the data cached and will not know that dbm has been modified.
> It's also worthwhile to use an external lock file because that properly
> locks for database creation.
That's for sure.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
