Hi Andrew, please take a look at the following Debian bug report. I've written a few comments at the end. (Please preserve [EMAIL PROTECTED] in the CC: list when responding, so that your responses can be tracked by the Debian BTS.)
On Sat 25 Nov 2006, Tim Connors wrote: > Subject: Bug#400329: wwwoffle: lock-files in concurrent downloading broken > either way > From: Tim Connors <[EMAIL PROTECTED]> > To: Debian Bug Tracking System <[EMAIL PROTECTED]> > Package: wwwoffle > Version: 2.9-2 > Severity: grave > Justification: causes non-serious data loss > > wwwoffle has the setting: > # lock-files = yes | no > # Enable the use of lock files to stop more than one WWWOFFLE process > # from downloading the same URL at the same time (default=no). > > Either way this is set, it is broken. > > If set to yes, it seems that a lockfile only manages to tell the > second process to give up loading the page at all, giving back a HTTP > 500 WWWOFFLE Server Error: > > > for i in `seq 1 10 ` ;do lynx -dump http://www.google.com.au & done > .... > WWWOFFLE - World Wide Web Offline Explorer - v2.9 > _________________________________________________________________ > > WWWOFFLE Server Error > > The WWWOFFLE server encountered a fatal error: > > Cannot open the spooled web page to read. > The program cannot continue to service this request. > > Help > > This is an internal WWWOFFLE server error that should not occur. There > is no other way of handling the error apart from providing this > warning page. If this error continues and WWWOFFLE is configured > correctly and there are no other computer problems then you should > report the error to the WWWOFFLE author. > _________________________________________________________________ > > WWWOFFLE - [[1]Welcome Page|[2]FAQ] - WWWOFFLE > > References > > 1. http://scuzzie:8080/Welcome.html > 2. http://scuzzie:8080/FAQ.html > ... > > By loading many pages at once as above, some of them end up succeeding > after the cache has been loaded, but prior to that, all but one of > them are going to fail -- above I'd see 5 or so error pages, then 5 or > so successful downloads -- YMW(ill)V as my computer is probably slow > enough for this test to come out this way. > > If set to no, then the first process to hit the cache gets their > download, but the second process only retrieves as much as had reached > the first process at that time. So the second download ends up > incomplete. No error is returned, so it may not even be apparent > until a later date -- hence dataloss. > > Marked as grave because of dataloss, since any webpage using crappy > session management, or submition of forms, etc, ends up being broken > whenever the page is being concurrently loaded in two seperate > pages/processes with either setting, and one copy will not be complete > or will fail altogether. Most of the rest of the time, a reload ought > to fix it, but this sometimes ends up loading from the browser's own > cache, which has only been half downloaded (I can't seem to convince > opera to drop its version of its cache, and reload from the proxy) I've responded that it's not a grave loss of data, as that's what the option is for; say "yes" if you want to prevent that. That said, the error you get when a page is indeed locked, is a bit unexpected: "This is an internal WWWOFFLE server error that should not occur." It's after all a documented option... IMHO the second process should wait for the completion of the first download process before proceeding; giving an "500 WWWOFFLE Server Error" is not the right thing to do here... thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
